linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Ravich, Leonid" <Leonid.Ravich@dell.com>
Cc: "Idgar, Or" <Or.Idgar@dell.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: CMA enhancement - non-default areas in x86
Date: Wed, 13 May 2020 10:33:43 +0200	[thread overview]
Message-ID: <20200513083343.GA772573@kroah.com> (raw)
In-Reply-To: <DM6PR19MB26827EFC4DDC6CB9DD5C52D098BF0@DM6PR19MB2682.namprd19.prod.outlook.com>

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, May 13, 2020 at 08:29:16AM +0000, Ravich, Leonid wrote:
> PCIe NTB 
> Documentation/driver-api/ntb.rst

> 1) Basically PCI bridge between to root complex / PCI switches 
> 2) using out of OS memory is one solution but then this memory is
> Limited for usage by other stack, ex: get_user_pages on this memory will fail, 
> Therefore attempting to use it for block layer with (o_direct) will fail. 
>  
> Acutely any generic stack which attempts to "pin" this memory will fail.

So why isn't the BIOS/UEFI properly reserving this from the general
operating system's pages so that the driver knows to use them instead?

Is UEFI wrong here about these being valid memory ranges for general
use?  If so, why not fix that?  If not, how in the world is the OS
supposed to know these memory ranges are _not_ for general use?  I feel
like there is something missing here...

thanks,

greg k-h


  reply	other threads:[~2020-05-13  8:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13  6:13 Idgar, Or
2020-05-13  6:47 ` gregkh
2020-05-13  7:00   ` Idgar, Or
2020-05-13  7:14     ` gregkh
2020-05-13  8:29       ` Ravich, Leonid
2020-05-13  8:33         ` gregkh [this message]
2020-05-13  9:43           ` Ravich, Leonid
2020-05-13 10:04             ` gregkh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200513083343.GA772573@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Leonid.Ravich@dell.com \
    --cc=Or.Idgar@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox