public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Matt Wilson" <msw@linux.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org,
	"David Vrabel" <david.vrabel@citrix.com>,
	"Matt Wilson" <msw@amazon.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] grant-table: don't set m2p override if kmap_ops is not set
Date: Wed, 06 Nov 2013 10:46:34 -0800	[thread overview]
Message-ID: <87a9hhweph.fsf@codemonkey.ws> (raw)
In-Reply-To: <1383733369.26213.45.camel@kazak.uk.xensource.com>

Ian Campbell <Ian.Campbell@citrix.com> writes:

> On Tue, 2013-11-05 at 12:53 -0800, Anthony Liguori wrote:
>> >> Yes, you are completely right, then I have to figure out why blkback
>> >> works fine with this patch applied (or at least it seems to work fine).
>> >
>> > blkback also works for me when testing a similar patch. I'm still
>> > confused. One thing with your proposed patch: I'm not sure that you're
>> > putting back the correct mfn.
>
> As long as it is unique and owned by the local domain I guess it doesn't
> matter which mfn goes back? It's going to get given back to the generic
> allocator so the content is irrelevant? (all speculation without looking
> at blkback)


Hrm, so m2p_add_override already does set_phys_to_machine(pfn,
FOREIGN_FRAME(mfn)) so this patch doesn't add anything that isn't
already there.  It's just removing the additional to the m2p override
table.

So what happens when the MFN isn't in the m2p override table?  It's
treated as a foreign PFN and m2p lookups fail.  But why is this a
problem for blkback?

>> It's perfectly fine to store a foreign pfn in the m2p table.
>
> No, it's not. The m2p is host global and maps mfns to the pfns in the
> owning domain. A domain which grant maps a foreign mfn into its address
> space doesn't get to update the m2p for that mfn. Perhaps you were
> thinking of the p2m?

Yes, I typoed that bit.

> Depending on how an OS mapping the foreign MFN does things it may well
> be accurate to say that having a foreign pfn in the m2p table is
> harmless, in as much as it will never try and use the m2p for foreign
> pages for anything real, but it depends on the implementation of the
> particular OS.

Note that this patch isn't doing anything to the m2p table.

>>   The m2p
>> override table is used by the grant device to allow a reverse lookup of
>> the real mfn to a pfn even if it's foreign.
>
> Classic Xen used an array of struct page * overrides in the struct vma
> for this sort of use case (e.g. in blktap). That obviously cannot fly
> for pvops...

I don't think the usage from blkback precludes using the gntdev either.
It just so happens that the m2p_add_override does extra work but I don't
think it actually benefits blkback in any way.

Am I missing something?

Regards,

Anthony Liguori

>
> Ian.

  reply	other threads:[~2013-11-06 18:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 11:24 [PATCH] grant-table: don't set m2p override if kmap_ops is not set Roger Pau Monne
2013-11-05 11:26 ` Roger Pau Monné
2013-11-05 12:36 ` David Vrabel
2013-11-05 14:47   ` Roger Pau Monné
2013-11-05 14:56     ` Konrad Rzeszutek Wilk
2013-11-05 15:01       ` Roger Pau Monné
2013-11-05 15:08         ` [Xen-devel] " Ian Campbell
2013-11-05 16:03           ` Roger Pau Monné
2013-11-05 20:06             ` Matt Wilson
2013-11-05 20:53               ` Anthony Liguori
2013-11-05 21:16                 ` Konrad Rzeszutek Wilk
2013-11-05 22:09                   ` Anthony Liguori
2013-11-05 22:19                     ` Matt Wilson
2013-11-06 10:22                 ` Ian Campbell
2013-11-06 18:46                   ` Anthony Liguori [this message]
2013-11-06 11:34                 ` David Vrabel
2013-11-06 17:59                   ` Matt Wilson
2013-11-06 18:52                     ` Konrad Rzeszutek Wilk
2013-11-07 20:15                       ` Stefano Stabellini

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=87a9hhweph.fsf@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=Ian.Campbell@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msw@amazon.com \
    --cc=msw@linux.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.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