From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Jan Beulich <jbeulich@suse.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork reset
Date: Fri, 24 Apr 2020 14:37:28 +0200 [thread overview]
Message-ID: <20200424123728.GI28601@Air-de-Roger> (raw)
In-Reply-To: <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
On Fri, Apr 24, 2020 at 06:18:24AM -0600, Tamas K Lengyel wrote:
> On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > > When resetting a VM fork we ought to only remove pages that were allocated for
> > > the fork during it's execution and the contents copied over from the parent.
> > > This can be determined if the page is sharable as special pages used by the
> > > fork for other purposes will not pass this test. Unfortunately during the fork
> > > reset loop we only partially check whether that's the case. A page's type may
> > > indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
> > > check by itself. All checks that are normally performed before a page is
> > > converted to the sharable type need to be performed to avoid removing pages
> > > from the p2m that may be used for other purposes. For example, currently the
> > > reset loop also removes the vcpu info pages from the p2m, potentially putting
> > > the guest into infinite page-fault loops.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> >
> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>
> Thanks!
>
> >
> > I've been looking however and I'm not able to spot where you copy the
> > shared_info data, which I think it's also quite critical for the
> > domain, as it contains the info about event channels (when using L2).
> > Also for HVM forks the shared info should be mapped at the same gfn as
> > the parent, or else the child trying to access it will trigger an EPT
> > fault that won't be able to populate such gfn, because the shared_info
> > on the parent is already shared between Xen and the parent.
>
> Pages that cause an EPT fault but can't be made shared get a new page
> allocated for them and copied in mem_sharing_fork_page. There are many
> pages like that, mostly due to QEMU mapping them and thus holding an
> extra reference. That said, shared_info is manually copied during
> forking in copy_special_pages, at the end of the function you will
> find:
>
> old_mfn = _mfn(virt_to_mfn(d->shared_info));
> new_mfn = _mfn(virt_to_mfn(cd->shared_info));
>
> copy_domain_page(new_mfn, old_mfn);
Oh, sorry for the noise, I somehow missed it.
Roger.
next prev parent reply other threads:[~2020-04-24 12:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 15:30 [PATCH v17 1/2] mem_sharing: fix sharability check during fork reset Tamas K Lengyel
2020-04-23 15:30 ` [PATCH v17 2/2] xen/tools: VM forking toolstack side Tamas K Lengyel
2020-04-24 13:11 ` Jan Beulich
2020-05-01 13:59 ` Tamas K Lengyel
2020-05-06 13:00 ` Wei Liu
2020-05-06 13:17 ` Tamas K Lengyel
2020-04-24 9:43 ` [PATCH v17 1/2] mem_sharing: fix sharability check during fork reset Roger Pau Monné
2020-04-24 12:18 ` Tamas K Lengyel
2020-04-24 12:37 ` Roger Pau Monné [this message]
2020-04-25 9:01 ` Roger Pau Monné
2020-04-25 12:31 ` Tamas K Lengyel
2020-04-27 8:27 ` Roger Pau Monné
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=20200424123728.GI28601@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=tamas.lengyel@intel.com \
--cc=tamas@tklengyel.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 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.