Re: [Xen-devel] [PATCH] xen: arm: configure correct dom0_gnttab_start/size

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-09-11 at 17:51 +0100, David Vrabel wrote:
> On 11/09/14 17:05, Ian Campbell wrote:
> > On Thu, 2014-09-11 at 16:54 +0100, Andrew Cooper wrote:
> >> Why it is hard coded at all? (x86 appears to manage fine.)  Without it
> >> being variably-located, there will always be a risk of collisions like 
> >> this.
> > 
> > For x86 PV (and shadow?) you can establish a mapping of the gnttab from
> > a virtual address directly to the machine address without needing a p2m
> > entry, via whichever hypercall it is which does that.
> > 
> > For HAP (and shadow?) you need a p2m mapping to get at the grant table,
> > so somewhere has to be found in the physical address space where it can
> > go.
> > 
> > In theory a guest kernel could try and find some io space which it isn't
> > using but to help them out we give them a hint.
> > 
> > For x86 HVM the IOBAR of the platform device as a handy place to put the
> > hint, for ARM domU we have a defined region in our address map which we
> > use and communicate via device tree.
> > 
> > But for ARM dom0 the physical address space layout follows the host,
> > figuring out a free bit of space is a bit tricky so each platform is
> > currently required (except some don't and there is a broken default) to
> > say where is a safe place to use (i.e. a person has to read the
> > datasheet and figure it out).
> 
> Linux x86 PVH dom0 and domU uses ballooned pages and they're vmap()'d in
> into a contiguous bit of virtual address space.
> 
> Perhaps something similar could be considered for ARM in the future?
> This would be common code between ARM and x86 PVH.

That would be good, yes.

Unfortunately the provision of this "hint" region is now part of our
ABI, so we can't just stop providing it, similar to how if PVHVM x86
switched to using ballooned pages you couldn't just remove the platform
devices IO BAR (not that it causes too much pain on x86, so you likely
wouldn't bother anyway).

Although there maybe migration paths which we can consider in both
cases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel