All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien@xen.org>
Cc: Luca Fancellu <Luca.Fancellu@arm.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	Penny Zheng <Penny.Zheng@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH 3/7] xen/p2m: put reference for superpage
Date: Thu, 9 May 2024 10:13:58 +0200	[thread overview]
Message-ID: <ZjyFxrvHJ04ZlBGg@macbook> (raw)
In-Reply-To: <64648f8c-3eea-47c5-bdc5-6d4fc6531c60@xen.org>

On Wed, May 08, 2024 at 11:11:04PM +0100, Julien Grall wrote:
> Hi,
> 
> CC-ing Roger as he is working on adding support for the foreign mapping on
> x86. Although, I am not expecting any implication as only 4KB mapping should
> be supported.

I don't think we have plans on x86 to support foreign mappings with
order != 0 ATM.

We would need a new interface to allow creating such mappings, and
it's also not clear to me how the domain that creates such mappings
can identify super-pages on the remote domain.  IOW: the mapping
domain could request a super-page in the foreign domain gfn space,
but that could end up being a range of lower order mappings.

Also the interactions with the remote domain would need to be audited,
as the remote domain shattering the superpage would need to be
replicated in the mapping side in order to account for the changes.

> On 08/05/2024 22:05, Julien Grall wrote:
> > On 07/05/2024 14:30, Luca Fancellu wrote:
> > > > On 7 May 2024, at 14:20, Julien Grall <julien@xen.org> wrote:
> > > > 
> > > > Hi Luca,
> > > > 
> > > > On 23/04/2024 09:25, Luca Fancellu wrote:
> > > > > From: Penny Zheng <Penny.Zheng@arm.com>
> > > > > But today, p2m_put_l3_page could not handle superpages.
> > > > 
> > > > This was done on purpose. Xen is not preemptible and therefore
> > > > we need to be cautious how much work is done within the p2m
> > > > code.
> > > > 
> > > > With the below proposal, for 1GB mapping, we may end up to call
> > > > put_page() up to 512 * 512 = 262144 times. put_page() can free
> > > > memory. This could be a very long operation.
> > > > 
> > > > Have you benchmark how long it would take?
> > > 
> > > I did not, since its purpose was unclear to me and was not commented
> > > in the last serie from Penny.
> > 
> > Honestly, I can't remember why it wasn't commented.
> 
> I skimmed through the code to check what we currently do for preemption.
> 
> {decrease, increase}_reservation() will allow to handle max_order() mapping
> at the time. On a default configuration, the max would be 4MB.
> 
> relinquish_p2m_mapping() is preempting every 512 iterations. One iteration
> is either a 4KB/2MB/1GB mapping.
> 
> relinquish_memory() is checking for preemption after every page.
> 
> So I think, it would be ok to allow 2MB mapping for static shared memory but
> not 1GB. relinquish_p2m_mapping() would also needs to be updated to take
> into account the larger foreign mapping.

FWIW, relinquish_p2m_mapping() likely does more than what's strictly
needed, as you could just remove foreign mappings while leaving other
entries as-is?  The drain of the p2m pool and release of domain pages
should take care of dropping references to the RAM domain memory?

> I would consider to check for preemption if 't' is p2m_map_foreign and the
> order is above 9 (i.e. 2MB).

How can those mappings be removed?  Is it possible for the guest to
modify such foreign super-pages?  Not sure all paths will be easy to
audit for preemption if it's more than relinquish_p2m_mapping() that
you need to adjust.

Regards, Roger.


  reply	other threads:[~2024-05-09  8:14 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-23  8:25 [PATCH 0/7] Static shared memory followup v2 - pt2 Luca Fancellu
2024-04-23  8:25 ` [PATCH 1/7] xen/arm: Lookup bootinfo shm bank during the mapping Luca Fancellu
2024-05-06 13:24   ` Michal Orzel
2024-05-07 13:44     ` Luca Fancellu
2024-05-07 14:01       ` Michal Orzel
2024-05-07 14:12         ` Luca Fancellu
2024-04-23  8:25 ` [PATCH 2/7] xen/arm: Wrap shared memory mapping code in one function Luca Fancellu
2024-05-06 13:39   ` Michal Orzel
2024-05-07 13:57     ` Luca Fancellu
2024-05-07 14:08       ` Michal Orzel
2024-05-07 14:15         ` Luca Fancellu
2024-05-08  6:33           ` Michal Orzel
2024-04-23  8:25 ` [PATCH 3/7] xen/p2m: put reference for superpage Luca Fancellu
2024-05-07 12:26   ` Michal Orzel
2024-05-07 13:20   ` Julien Grall
2024-05-07 13:30     ` Luca Fancellu
2024-05-08 21:05       ` Julien Grall
2024-05-08 22:11         ` Julien Grall
2024-05-09  8:13           ` Roger Pau Monné [this message]
2024-05-09  9:50             ` Julien Grall
2024-05-09 11:28               ` Roger Pau Monné
2024-05-09 12:12                 ` Julien Grall
2024-05-09 12:58                   ` Roger Pau Monné
2024-05-10 21:37                     ` Julien Grall
2024-05-13  8:04                       ` Roger Pau Monné
2024-05-14  7:55                       ` Luca Fancellu
2024-05-09  7:55   ` Roger Pau Monné
2024-04-23  8:25 ` [PATCH 4/7] xen/arm: Parse xen,shared-mem when host phys address is not provided Luca Fancellu
2024-05-08 12:09   ` Michal Orzel
2024-05-08 13:28     ` Luca Fancellu
2024-05-09  8:58       ` Luca Fancellu
2024-04-23  8:25 ` [PATCH 5/7] xen/arm: Rework heap page allocation outside allocate_bank_memory Luca Fancellu
2024-05-09 11:04   ` Michal Orzel
2024-04-23  8:25 ` [PATCH 6/7] xen/arm: Implement the logic for static shared memory from Xen heap Luca Fancellu
2024-05-10  9:17   ` Michal Orzel
2024-05-10  9:25     ` Luca Fancellu
2024-05-10  9:32       ` Michal Orzel
2024-05-10  9:37         ` Luca Fancellu
2024-04-23  8:25 ` [PATCH 7/7] xen/docs: Describe static shared memory when host address is not provided Luca Fancellu
2024-05-10  9:33   ` Michal Orzel

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=ZjyFxrvHJ04ZlBGg@macbook \
    --to=roger.pau@citrix.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Luca.Fancellu@arm.com \
    --cc=Penny.Zheng@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.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.