xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Elliott Mitchell <ehem+undef@m5p.com>
To: Julien Grall <julien@xen.org>
Cc: xen-devel@lists.xenproject.org,
	Roger Pau Monn?? <royger@freebsd.org>,
	Mitchell Horne <mhorne@freebsd.org>
Subject: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues)
Date: Thu, 13 May 2021 19:42:28 -0700	[thread overview]
Message-ID: <YJ3jlGSxs60Io+dp@mattapan.m5p.com> (raw)
In-Reply-To: <54427968-9b13-36e6-0001-27fb49f85635@xen.org>

Upon thinking about it, this seems appropriate to bring to the attention
of the Xen development list since it seems to have wider implications.


On Wed, May 12, 2021 at 11:08:39AM +0100, Julien Grall wrote:
> On 12/05/2021 03:37, Elliott Mitchell wrote:
> > 
> > What about the approach to the grant-table/xenpv memory situation?
> > 
> > As stated for a 768MB VM, Xen suggested a 16MB range.  I'm unsure whether
> > that is strictly meant for grant-table use or is meant for any foreign
> > memory mappings (Julien?).
> 
> An OS is free to use it as it wants. However, there is no promise that:
>    1) The region will not shrink
>    2) The region will stay where it is

Issue is what is the intended use of the memory range allocated to
/hypervisor in the device-tree on ARM?  What do the Xen developers plan
for?  What is expected?


With FreeBSD, Julien Grall's attempt 5 years ago at getting Xen/ARM
support treated the grant table as distinct from other foreign memory
mappings.  Yet for the current code (which is oriented towards x86) it is
rather easier to treat all foreign mappings the same.

Limiting foreign mappings to a total of 16MB for a 768MB domain is tight.
Was the /hypervisor range intended *strictly* for mapping grant-tables?
Was it intended for the /hypervisor range to dynamically scale with the
size of the domain?  Was it intended for /hypervisor to grow over the
years as hardware got cheaper?

Might it be better to deprecate the /hypervisor range and have domains
allocate any available address space for foreign mappings?

Should the FreeBSD implementation be treating grant tables as distinct
from other foreign mappings?  (is treating them the same likely to
induce buggy behavior on x86?)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




       reply	other threads:[~2021-05-14  2:42 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 [this message]
2021-05-14  8:32                     ` Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues) 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
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=YJ3jlGSxs60Io+dp@mattapan.m5p.com \
    --to=ehem+undef@m5p.com \
    --cc=julien@xen.org \
    --cc=mhorne@freebsd.org \
    --cc=royger@freebsd.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).