xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Tamas K Lengyel" <tamas.lengyel@intel.com>,
	"Wei Liu" <wl@xen.org>,
	"George Dunlap" <george.dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries
Date: Wed, 22 Jan 2020 09:51:06 -0700	[thread overview]
Message-ID: <CABfawhkzPyFas7kasNjBoCyCMi+kkfC6DrvYv4PCuPtK7A5MNA@mail.gmail.com> (raw)
In-Reply-To: <6cb72a36-d9af-5b96-76df-2c6746dfa245@suse.com>

On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 21.01.2020 18:49, Tamas K Lengyel wrote:
> > The owner domain of shared pages is dom_cow, use that for get_page
> > otherwise the function fails to return the correct page.
>
> I think this description needs improvement: The function does the
> special shared page dance in one place (on the "fast path")
> already. This wants mentioning, either because it was a mistake
> to have it just there, or because a new need has appeared to also
> have it on the "slow path".

It was a pre-existing error not to get the page from dom_cow for a
shared entry in the slow path. I only ran into it now because the
erroneous type_count check move in the previous version of the series
was resulting in all pages being fully deduplicated instead of mostly
being shared. Now that the pages are properly shared running LibVMI on
the fork resulted in failures do to this bug.

> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -594,7 +594,10 @@ struct page_info *p2m_get_page_from_gfn(
> >      if ( p2m_is_ram(*t) && mfn_valid(mfn) )
> >      {
> >          page = mfn_to_page(mfn);
> > -        if ( !get_page(page, p2m->domain) )
> > +        if ( !get_page(page, p2m->domain) &&
> > +             /* Page could be shared */
> > +             (!dom_cow || !p2m_is_shared(*t) ||
> > +              !get_page(page, dom_cow)) )
>
> While there may be a reason why on the fast path two get_page()
> invocations are be necessary, couldn't you get away with just
> one
>
>         if ( !get_page(page, !dom_cow || !p2m_is_shared(*t) ? p2m->domain
>                                                             : dom_cow) )
>
> at least here? It's also not really clear to me why here and
> there we need "!dom_cow || !p2m_is_shared(*t)" - wouldn't
> p2m_is_shared() return consistently "false" when !dom_cow ?

I simply copied the existing code from the slow_path as-is. IMHO it
would suffice to do a single get_page(page, !p2m_is_shared(*t) ?
p2m->domain : dom_cow);  since we can't have any entries that are
shared when dom_cow is NULL so this is safe, no need for the extra
!dom_cow check. If you prefer I can make the change for both
locations.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-22 16:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 17:49 [Xen-devel] [PATCH v5 00/18] VM forking Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 01/18] x86/hvm: introduce hvm_copy_context_and_params Tamas K Lengyel
2020-01-22 15:00   ` Jan Beulich
2020-01-22 16:42     ` Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 02/18] xen/x86: Make hap_get_allocation accessible Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries Tamas K Lengyel
2020-01-22 15:23   ` Jan Beulich
2020-01-22 16:51     ` Tamas K Lengyel [this message]
2020-01-22 16:55       ` Jan Beulich
2020-01-23 15:32         ` George Dunlap
2020-01-23 15:48           ` Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 04/18] x86/mem_sharing: make get_two_gfns take locks conditionally Tamas K Lengyel
2020-01-23 15:50   ` George Dunlap
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 05/18] x86/mem_sharing: drop flags from mem_sharing_unshare_page Tamas K Lengyel
2020-01-23 15:53   ` George Dunlap
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 06/18] x86/mem_sharing: don't try to unshare twice during page fault Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 07/18] x86/mem_sharing: define mem_sharing_domain to hold some scattered variables Tamas K Lengyel
2020-01-23 15:59   ` George Dunlap
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 08/18] x86/mem_sharing: Use INVALID_MFN and p2m_is_shared in relinquish_shared_pages Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 09/18] x86/mem_sharing: Make add_to_physmap static and shorten name Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool Tamas K Lengyel
2020-01-23 16:14   ` George Dunlap
2020-01-23 16:23     ` Tamas K Lengyel
2020-01-23 16:32       ` George Dunlap
2020-01-23 16:37         ` Jan Beulich
2020-01-23 16:42           ` George Dunlap
2020-01-23 16:55             ` Jan Beulich
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 11/18] x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk Tamas K Lengyel
2020-01-22 15:30   ` Jan Beulich
2020-01-22 16:55     ` Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 12/18] x86/mem_sharing: Enable mem_sharing on first memop Tamas K Lengyel
2020-01-22 15:32   ` Jan Beulich
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 13/18] x86/mem_sharing: Skip xen heap pages in memshr nominate Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 14/18] x86/mem_sharing: use default_access in add_to_physmap Tamas K Lengyel
2020-01-22 15:35   ` Jan Beulich
2020-01-22 17:08     ` Tamas K Lengyel
2020-01-23 16:44       ` George Dunlap
2020-01-23 17:19         ` Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 15/18] xen/mem_sharing: VM forking Tamas K Lengyel
2020-01-23 17:21   ` George Dunlap
2020-01-23 17:30     ` Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 16/18] xen/mem_access: Use __get_gfn_type_access in set_mem_access Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 17/18] x86/mem_sharing: reset a fork Tamas K Lengyel
2020-01-21 17:49 ` [Xen-devel] [PATCH v5 18/18] xen/tools: VM forking toolstack side Tamas K Lengyel

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=CABfawhkzPyFas7kasNjBoCyCMi+kkfC6DrvYv4PCuPtK7A5MNA@mail.gmail.com \
    --to=tamas.k.lengyel@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=tamas.lengyel@intel.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).