From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org, bertrand.marquis@arm.com,
Julien Grall <julien.grall@arm.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH RFC 4/6] xen/arm: mm: Allow other mapping size in xen_pt_update_entry()
Date: Mon, 23 Nov 2020 14:27:52 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.21.2011231409050.7979@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <1ba4afef-7efa-6d1a-5929-ec2652dbbb21@xen.org>
On Fri, 20 Nov 2020, Julien Grall wrote:
> > > /*
> > > * For arm32, page-tables are different on each CPUs. Yet, they
> > > share
> > > @@ -1265,14 +1287,43 @@ static int xen_pt_update(unsigned long virt,
> > > spin_lock(&xen_pt_lock);
> > > - for ( ; addr < addr_end; addr += PAGE_SIZE )
> > > + while ( left )
> > > {
> > > - rc = xen_pt_update_entry(root, addr, mfn, flags);
> > > + unsigned int order;
> > > + unsigned long mask;
> > > +
> > > + /*
> > > + * Don't take into account the MFN when removing mapping (i.e
> > > + * MFN_INVALID) to calculate the correct target order.
> > > + *
> > > + * XXX: Support superpage mappings if nr is not aligned to a
> > > + * superpage size.
> >
> > It would be good to add another sentence to explain that the checks
> > below are simply based on masks and rely on the mfn, vfn, and also
> > nr_mfn to be superpage aligned. (It took me some time to figure it out.)
>
> I am not sure to understand what you wrote here. Could you suggest a sentence?
Something like the following:
/*
* Don't take into account the MFN when removing mapping (i.e
* MFN_INVALID) to calculate the correct target order.
*
* This loop relies on mfn, vfn, and nr_mfn, to be all superpage
* aligned, and it uses `mask' to check for that.
*
* XXX: Support superpage mappings if nr_mfn is not aligned to a
* superpage size.
*/
> Regarding the TODO itself, we have the exact same one in the P2M code. I
> couldn't find a clever way to deal with it yet. Any idea how this could be
> solved?
I was thinking of a loop that start with the highest possible superpage
size that virt and mfn are aligned to, and also smaller or equal to
nr_mfn. So rather than using the mask to also make sure nr_mfns is
aligned, I would only use the mask to check that mfn and virt are
aligned. Then, we only need to check that superpage_size <= left.
Concrete example: virt and mfn are 2MB aligned, nr_mfn is 5MB / 1280 4K
pages. We allocate 2MB superpages until onlt 1MB is left. At that point
superpage_size <= left fails and we go down to 4K allocations.
Would that work?
next prev parent reply other threads:[~2020-11-23 22:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 19:07 [PATCH RFC 0/6] xen/arm: mm: Add limited support for superpages Julien Grall
2020-11-19 19:07 ` [PATCH RFC 1/6] xen/arm: mm: Remove special case for CPU0 in dump_hyp_walk() Julien Grall
2020-11-24 17:10 ` Bertrand Marquis
2020-11-28 11:14 ` Julien Grall
2020-11-30 21:58 ` Stefano Stabellini
2020-11-19 19:07 ` [PATCH RFC 2/6] xen/arm: mm: Remove ; at the end of mm_printk() Julien Grall
2020-11-20 0:41 ` Stefano Stabellini
2020-11-24 12:19 ` Bertrand Marquis
2020-11-19 19:07 ` [PATCH RFC 3/6] xen/arm: setup: Call unregister_init_virtual_region() after the last init function Julien Grall
2020-11-24 13:25 ` Bertrand Marquis
2020-11-19 19:07 ` [PATCH RFC 4/6] xen/arm: mm: Allow other mapping size in xen_pt_update_entry() Julien Grall
2020-11-20 1:46 ` Stefano Stabellini
2020-11-20 16:09 ` Julien Grall
2020-11-23 22:27 ` Stefano Stabellini [this message]
2020-11-23 23:23 ` Julien Grall
2020-11-24 0:25 ` Stefano Stabellini
2020-11-28 11:53 ` Julien Grall
2020-11-30 22:05 ` Stefano Stabellini
2021-04-25 15:11 ` Julien Grall
2020-11-24 18:13 ` Bertrand Marquis
2020-11-25 18:03 ` Julien Grall
2020-11-19 19:07 ` [PATCH RFC 5/6] xen/arm: mm: Don't open-code Xen PT update in remove_early_mappings Julien Grall
2020-11-20 1:47 ` Stefano Stabellini
2020-11-19 19:07 ` [PATCH RFC 6/6] xen/arm: mm: Re-implement early_fdt_map() using map_pages_to_xen() Julien Grall
2020-11-20 1:54 ` Stefano Stabellini
2021-01-23 11:44 ` [PATCH RFC 0/6] xen/arm: mm: Add limited support for superpages Julien Grall
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=alpine.DEB.2.21.2011231409050.7979@sstabellini-ThinkPad-T480s \
--to=sstabellini@kernel.org \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=julien.grall@arm.com \
--cc=julien@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).