From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Subject: Re: [PATCH 05/12] xen: add m2p override mechanism
Date: Tue, 11 Jan 2011 10:24:40 -0500 [thread overview]
Message-ID: <20110111152439.GB10897@dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1101111202020.7277@kaball-desktop>
On Tue, Jan 11, 2011 at 12:44:39PM +0000, Stefano Stabellini wrote:
> On Mon, 10 Jan 2011, Konrad Rzeszutek Wilk wrote:
> > > @@ -83,6 +85,14 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
> > > */
> > > __get_user(pfn, &machine_to_phys_mapping[mfn]);
> > >
> > > + /*
> > > + * If this appears to be a foreign mfn (because the pfn
> > > + * doesn't map back to the mfn), then check the local override
> > > + * table to see if there's a better pfn to use.
> > > + */
> > > + if (get_phys_to_machine(pfn) != mfn)
> >
> > Any reason to not use 'pfn_to_mfn' call instead? If we do want
> > to use the get_hhys_to_machine wouldn't be easier to just
> > check for 'FOREIGN_FRAME_BIT' set? Or is just mostly a copy-n-paste
> > of mfn_to_local_pfn?
>
>
> pfn in this case is the return value of m2p(mfn); there are 3 possible
> cases:
>
> 1) the mfn was a regular ram page belonging to the domain so
> get_phys_to_machine(pfn) == mfn. Nothing to see here.
>
> 2) the mfn was a granted page so pfn is actually the pfn in the source
> domain and doesn't mean anything in our domain.
> In this case get_phys_to_machine(pfn) is always different from mfn,
> either because the mapping in our domain is just different or because
> the FOREIGN_FRAME_BIT is set.
>
> 3) the pfn belongs to a 1:1 region. In this case
> get_phys_to_machine(pfn) != mfn because of the IDENTITY_FRAME_BIT but we
> don't actually want to look in the m2p_override because we are not going
> to find anything useful there.
>
>
> Considering all this, I propose this change:
>
> if (get_phys_to_machine(pfn) != mfn)
>
> into
>
> if (pfn_to_mfn(pfn) != mfn)
>
> because:
>
> - it won't make any differences in case 1);
>
> - it will avoid false potives in case 3);
>
> - in case 2) if p2m(pfn) => mfn in both the source and the destination
> domain then we might skip the check in the m2p_override but we don't
> care because by luck we got the correct value anyway (m2p(mfn) ==
> m2p_override(mfn)).
>
>
>
> However I understand that it might be subtle and needs a very long
> comment so a simpler alternative would be to explicitly remove the
> IDENTITY_FRAME_BIT from the check:
>
> if ((get_phys_to_machine(pfn) & ~IDENTITY_FRAME_BIT) != mfn)
Thank you analyzing this in such depth. Let me create a branch with
this patchset (devel/grantdev.v2), merge it with the devel/p2m-identity one and
then on top of that create a patch that will what you just suggested (removing
the IDENTITY_FRAME_BIT) and make the author you.
That way we have something we can test with both modifications to the
P2M and M2P lookups and weed out any bugs.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/12] xen: add m2p override mechanism
Date: Tue, 11 Jan 2011 10:24:40 -0500 [thread overview]
Message-ID: <20110111152439.GB10897@dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1101111202020.7277@kaball-desktop>
On Tue, Jan 11, 2011 at 12:44:39PM +0000, Stefano Stabellini wrote:
> On Mon, 10 Jan 2011, Konrad Rzeszutek Wilk wrote:
> > > @@ -83,6 +85,14 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
> > > */
> > > __get_user(pfn, &machine_to_phys_mapping[mfn]);
> > >
> > > + /*
> > > + * If this appears to be a foreign mfn (because the pfn
> > > + * doesn't map back to the mfn), then check the local override
> > > + * table to see if there's a better pfn to use.
> > > + */
> > > + if (get_phys_to_machine(pfn) != mfn)
> >
> > Any reason to not use 'pfn_to_mfn' call instead? If we do want
> > to use the get_hhys_to_machine wouldn't be easier to just
> > check for 'FOREIGN_FRAME_BIT' set? Or is just mostly a copy-n-paste
> > of mfn_to_local_pfn?
>
>
> pfn in this case is the return value of m2p(mfn); there are 3 possible
> cases:
>
> 1) the mfn was a regular ram page belonging to the domain so
> get_phys_to_machine(pfn) == mfn. Nothing to see here.
>
> 2) the mfn was a granted page so pfn is actually the pfn in the source
> domain and doesn't mean anything in our domain.
> In this case get_phys_to_machine(pfn) is always different from mfn,
> either because the mapping in our domain is just different or because
> the FOREIGN_FRAME_BIT is set.
>
> 3) the pfn belongs to a 1:1 region. In this case
> get_phys_to_machine(pfn) != mfn because of the IDENTITY_FRAME_BIT but we
> don't actually want to look in the m2p_override because we are not going
> to find anything useful there.
>
>
> Considering all this, I propose this change:
>
> if (get_phys_to_machine(pfn) != mfn)
>
> into
>
> if (pfn_to_mfn(pfn) != mfn)
>
> because:
>
> - it won't make any differences in case 1);
>
> - it will avoid false potives in case 3);
>
> - in case 2) if p2m(pfn) => mfn in both the source and the destination
> domain then we might skip the check in the m2p_override but we don't
> care because by luck we got the correct value anyway (m2p(mfn) ==
> m2p_override(mfn)).
>
>
>
> However I understand that it might be subtle and needs a very long
> comment so a simpler alternative would be to explicitly remove the
> IDENTITY_FRAME_BIT from the check:
>
> if ((get_phys_to_machine(pfn) & ~IDENTITY_FRAME_BIT) != mfn)
Thank you analyzing this in such depth. Let me create a branch with
this patchset (devel/grantdev.v2), merge it with the devel/p2m-identity one and
then on top of that create a patch that will what you just suggested (removing
the IDENTITY_FRAME_BIT) and make the author you.
That way we have something we can test with both modifications to the
P2M and M2P lookups and weed out any bugs.
next prev parent reply other threads:[~2011-01-11 15:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-10 10:36 [PATCH v2 00/12] xen: allow usermode to map granted pages Stefano Stabellini
2011-01-10 10:36 ` [PATCH 01/12] xen: define gnttab_set_map_op/unmap_op stefano.stabellini
2011-01-10 10:36 ` [PATCH 02/12] xen/gntdev: allow usermode to map granted pages stefano.stabellini
2011-01-10 10:36 ` [PATCH 03/12] xen/gntdev: add VM_PFNMAP to vma stefano.stabellini
2011-01-10 10:36 ` [PATCH 04/12] xen: move p2m handling to separate file stefano.stabellini
2011-01-10 10:36 ` [PATCH 05/12] xen: add m2p override mechanism stefano.stabellini
2011-01-10 23:11 ` Konrad Rzeszutek Wilk
2011-01-11 12:44 ` Stefano Stabellini
2011-01-11 15:24 ` Konrad Rzeszutek Wilk [this message]
2011-01-11 15:24 ` Konrad Rzeszutek Wilk
2011-01-10 10:36 ` [PATCH 06/12] xen: gntdev: move use of GNTMAP_contains_pte next to the map_op stefano.stabellini
2011-01-10 10:36 ` [PATCH 07/12] xen/gntdev: stop using "token" argument stefano.stabellini
2011-01-10 10:36 ` [PATCH 08/12] xen/gntdev: Fix circular locking dependency stefano.stabellini
2011-01-10 10:36 ` [PATCH 09/12] xen p2m: transparently change the p2m mappings in the m2p override stefano.stabellini
2011-01-10 10:36 ` [PATCH 10/12] xen: introduce gnttab_map_refs and gnttab_unmap_refs stefano.stabellini
2011-01-10 10:36 ` [PATCH 11/12] xen gntdev: use " stefano.stabellini
2011-01-10 10:36 ` [PATCH 12/12] xen p2m: clear the old pte when adding a page to m2p_override 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=20110111152439.GB10897@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Jeremy.Fitzhardinge@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.