From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: jgrall@amazon.com, "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"George Dunlap" <george.dunlap@citrix.com>,
"Ian Jackson" <iwj@xenproject.org>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v9 01/13] x86/mm: rewrite virt_to_xen_l*e
Date: Wed, 21 Apr 2021 12:33:05 +0100 [thread overview]
Message-ID: <2ceae314e9e634ef7e9bebf7f64653f25fa97dd6.camel@xen.org> (raw)
In-Reply-To: <fbc4a42f-549b-515f-279f-92466f89af79@suse.com>
On Tue, 2021-04-20 at 14:17 +0200, Jan Beulich wrote:
> On 06.04.2021 13:05, Hongyan Xia wrote:
> > From: Wei Liu <wei.liu2@citrix.com>
> >
> > Rewrite those functions to use the new APIs. Modify its callers to
> > unmap
> > the pointer returned. Since alloc_xen_pagetable_new() is almost
> > never
> > useful unless accompanied by page clearing and a mapping, introduce
> > a
> > helper alloc_map_clear_xen_pt() for this sequence.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> >
> > ---
> > Changed in v9:
> > - use domain_page_map_to_mfn() around the L3 table locking logic.
> > - remove vmap_to_mfn() changes since we now use xen_map_to_mfn().
> >
> > Changed in v8:
> > - s/virtual address/linear address/.
> > - BUG_ON() on NULL return in vmap_to_mfn().
> >
> > Changed in v7:
> > - remove a comment.
> > - use l1e_get_mfn() instead of converting things back and forth.
> > - add alloc_map_clear_xen_pt().
>
> I realize this was in v7 already, but at v6 time the name I suggested
> was
>
> void *alloc_mapped_pagetable(mfn_t *mfn);
>
> "alloc_map_clear_xen", for my taste at least, is too strange. It
> doesn't really matter whether it's a page table for Xen's own use
> (it typically will be), so "xen" could be dropped. Clearing of a
> page table ought to also be the rule rather than the exception, so
> I'd see "clear" also dropped. I'd be fine with alloc_map_pt() or
> about any intermediate variant between that and my originally
> suggested name.
Sounds reasonable. I will go with alloc_mapped_pagetable().
>
> > @@ -5108,7 +5140,8 @@ int map_pages_to_xen(
> > unsigned int flags)
> > {
> > bool locking = system_state > SYS_STATE_boot;
> > - l2_pgentry_t *pl2e, ol2e;
> > + l3_pgentry_t *pl3e = NULL, ol3e;
> > + l2_pgentry_t *pl2e = NULL, ol2e;
> > l1_pgentry_t *pl1e, ol1e;
> > unsigned int i;
> > int rc = -ENOMEM;
> > @@ -5132,15 +5165,16 @@ int map_pages_to_xen(
> >
> > while ( nr_mfns != 0 )
> > {
> > - l3_pgentry_t *pl3e, ol3e;
> > -
> > + /* Clean up the previous iteration. */
> > L3T_UNLOCK(current_l3page);
> > + UNMAP_DOMAIN_PAGE(pl3e);
> > + UNMAP_DOMAIN_PAGE(pl2e);
>
> Doing this here suggests the lower-case equivalent is needed at the
> out label, even without looking at the rest of the function (doing
> so confirms the suspicion, as there's at least one "goto out" with
> pl2e clearly still mapped).
>
> > @@ -5305,6 +5339,8 @@ int map_pages_to_xen(
> > pl1e = virt_to_xen_l1e(virt);
> > if ( pl1e == NULL )
> > goto out;
> > +
> > + UNMAP_DOMAIN_PAGE(pl1e);
> > }
>
> Unmapping the page right after mapping it looks suspicious. I see
> that
> further down we have
>
> pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(virt);
>
> but don't you need to also change that? Actually, you do in patch 2,
> but the latest then the double mapping should imo be avoided.
I would say the code was already suspicious to begin with, since pl1e
would be overwritten immediately below even before this patch. The
purpose of the virt_to_xen_l1e() is only to populate the L1 table.
Performance-wise the double map should be pretty harmless since the
mapping is in the cache, so I actually prefer it as is. Alternatively,
I can initialise pl1e to NULL at the beginning of the block and only do
the
pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(virt);
when the pl1e is still NULL. If you are okay I will go with this.
>
> > @@ -5505,6 +5542,7 @@ int populate_pt_range(unsigned long virt,
> > unsigned long nr_mfns)
> > int modify_xen_mappings(unsigned long s, unsigned long e, unsigned
> > int nf)
> > {
> > bool locking = system_state > SYS_STATE_boot;
> > + l3_pgentry_t *pl3e = NULL;
> > l2_pgentry_t *pl2e;
> > l1_pgentry_t *pl1e;
> > unsigned int i;
>
> And here we have the opposite situation: You don't set pl2e to NULL
> and the function only uses l3e_to_l2e() to initialize the variable,
> yet ...
>
> > @@ -5761,6 +5799,8 @@ int modify_xen_mappings(unsigned long s,
> > unsigned long e, unsigned int nf)
> >
> > out:
> > L3T_UNLOCK(current_l3page);
> > + unmap_domain_page(pl2e);
> > + unmap_domain_page(pl3e);
>
> ... here you try to unmap it. Did the two respective hunks somehow
> magically get swapped?
Since the +-3 contexts of the two hunks are exactly the same, I have
strong suspicion what you said is exactly what happened. Thank you for
spotting this.
>
> > --- a/xen/common/vmap.c
> > +++ b/xen/common/vmap.c
> > @@ -1,6 +1,7 @@
> > #ifdef VMAP_VIRT_START
> > #include <xen/bitmap.h>
> > #include <xen/cache.h>
> > +#include <xen/domain_page.h>
>
> Why is this needed? (Looks like a now stale change.)
Stale change indeed. Will be removed.
Hongyan
next prev parent reply other threads:[~2021-04-21 11:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-06 11:05 [PATCH v9 00/13] switch to domheap for Xen page tables Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 01/13] x86/mm: rewrite virt_to_xen_l*e Hongyan Xia
2021-04-20 12:17 ` Jan Beulich
2021-04-21 11:33 ` Hongyan Xia [this message]
2021-04-21 11:39 ` Jan Beulich
2021-04-06 11:05 ` [PATCH v9 02/13] x86/mm: switch to new APIs in map_pages_to_xen Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 03/13] x86/mm: switch to new APIs in modify_xen_mappings Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 04/13] x86_64/mm: introduce pl2e in paging_init Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 05/13] x86_64/mm: switch to new APIs " Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 06/13] x86_64/mm: switch to new APIs in setup_m2p_table Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 07/13] efi: use new page table APIs in copy_mapping Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 08/13] efi: switch to new APIs in EFI code Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 09/13] x86/smpboot: add exit path for clone_mapping() Hongyan Xia
2021-04-20 12:29 ` Jan Beulich
2021-04-06 11:05 ` [PATCH v9 10/13] x86/smpboot: switch clone_mapping() to new APIs Hongyan Xia
2021-04-20 12:32 ` Jan Beulich
2021-04-21 13:39 ` Hongyan Xia
2021-04-06 11:05 ` [PATCH v9 11/13] x86/mm: drop old page table APIs Hongyan Xia
2021-04-06 11:06 ` [PATCH v9 12/13] x86: switch to use domheap page for page tables Hongyan Xia
2021-04-06 11:06 ` [PATCH v9 13/13] x86/mm: drop _new suffix for page table APIs Hongyan Xia
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=2ceae314e9e634ef7e9bebf7f64653f25fa97dd6.camel@xen.org \
--to=hx242@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=jgrall@amazon.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--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).