xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	 Elliott Mitchell <ehem+xen@m5p.com>,
	xen-devel@lists.xenproject.org,
	 Roger Pau Monn?? <royger@freebsd.org>,
	Mitchell Horne <mhorne@freebsd.org>,
	 Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues)
Date: Thu, 20 May 2021 09:21:40 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2105200919100.14426@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <b6fe6e06-517c-ee4c-5b71-a1bee4d4df13@xen.org>

On Thu, 20 May 2021, Julien Grall wrote:
> On 20/05/2021 00:25, Stefano Stabellini wrote:
> > On Sat, 15 May 2021, Julien Grall wrote:
> > > > My feeling is one of two things should happen with the /hypervisor
> > > > address range:
> > > > 
> > > > 1>  OSes could be encouraged to use it for all foreign mappings.  The
> > > > range should be dynamic in some fashion.  There could be a handy way to
> > > > allow configuring the amount of address space thus reserved.
> > > 
> > > In the context of XSA-300 and virtio on Xen on Arm, we discussed about
> > > providing a revion for foreign mapping. The main trouble here is figuring
> > > out
> > > of the size, if you mess it up then you may break all the PV drivers.
> > > 
> > > If the problem is finding space, then I would like to suggest a different
> > > approach (I think I may have discussed it with Andrew). Xen is in
> > > maintaining
> > > the P2M for the guest and therefore now where are the unallocated space.
> > > How
> > > about introducing a new hypercall to ask for "unallocated space"?
> > > 
> > > This would not work for older hypervisor but you could use the RAM instead
> > > (as
> > > Linux does). This is has drawbacks (e.g. shattering superpage, reducing
> > > the
> > > amount of memory usuable...), but for 1> you would also need a hack for
> > > older
> > > Xen.
> > 
> > I am starting to wonder if it would make sense to add a new device tree
> > binding to describe larger free region for foreign mapping rather then a
> > hypercall. It could be several GBs or even TBs in size. I like the idea
> > of having it device tree because after all this is static information.
> > I can see that a hypercall would also work and I am open to it but if
> > possible I think it would be better not to extend the hypercall
> > interface when there is a good alternative.
> 
> There are two issues with the Device-Tree approach:
>   1) This doesn't work on ACPI
>   2) It is not clear how to define the size of the region. An admin doesn't
> have the right information in hand to know how many mappings will be done (a
> backend may map multiple time the same page).
> 
> The advantage of the hypercall solution is the size is "virtually" unlimited
> and not based on a specific firmware.

Fair enough


  reply	other threads:[~2021-05-20 16:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YIhSbkfShjN/gMCe@Air-de-Roger>
     [not found] ` <YIndyh0sRqcmcMim@mattapan.m5p.com>
     [not found]   ` <YIptpndhk6MOJFod@Air-de-Roger>
     [not found]     ` <YItwHirnih6iUtRS@mattapan.m5p.com>
     [not found]       ` <YIu80FNQHKS3+jVN@Air-de-Roger>
     [not found]         ` <YJDcDjjgCsQUdsZ7@mattapan.m5p.com>
     [not found]           ` <YJURGaqAVBSYnMRf@Air-de-Roger>
     [not found]             ` <YJYem5CW/97k/e5A@mattapan.m5p.com>
     [not found]               ` <YJs/YAgB8molh7e5@mattapan.m5p.com>
     [not found]                 ` <54427968-9b13-36e6-0001-27fb49f85635@xen.org>
2021-05-14  2:42                   ` Elliott Mitchell
2021-05-14  8:32                     ` Julien Grall
2021-05-14 10:07                       ` Roger Pau Monné
2021-05-15  1:18                       ` Elliott Mitchell
2021-05-15 10:08                         ` Julien Grall
2021-05-19 23:25                           ` Stefano Stabellini
2021-05-20  9:51                             ` Julien Grall
2021-05-20 16:21                               ` Stefano Stabellini [this message]
2021-06-18 12:19                                 ` Oleksandr Andrushchenko
2021-07-03 17:17                                   ` Julien Grall
2021-07-22 20:41                                     ` Oleksandr Tyshchenko

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.2105200919100.14426@sstabellini-ThinkPad-T480s \
    --to=sstabellini@kernel.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=ehem+xen@m5p.com \
    --cc=julien@xen.org \
    --cc=mhorne@freebsd.org \
    --cc=royger@freebsd.org \
    --cc=xen-devel@lists.xenproject.org \
    --subject='Re: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues)' \
    /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

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).