Re: PCI Pass-through in Xen ARM: Draft 4

[Ian Campbell <ian.campbell@citrix.com>]

On Wed, 2015-09-02 at 14:46 +0100, Ian Campbell wrote:
> On Wed, 2015-09-02 at 13:59 +0100, Julien Grall wrote:
> 
> (I'm not caught up on my mail, so just commenting on this one aspect)
> 
> > Anyway, I think this logic should be done in the toolstack and not in
> > the hypervisor. Only the toolstack is in charge of the memory layout.
> > Xen appears to know the memory layout on ARM because it's statically 
> > define.
> 
> The domU address space GUEST_* #defines in xen/include/public/arch-arm.h
> are really just a convenience used when the toolstack and hypervisor need
> to agree on a value and that value happens, right now, to be static.
> 
> The _correct_ interface would be a hypercall (or several) where the
> toolstack tells Xen what the values are, but that's code and faff etc so
> where the value which the toolstack is static we take a short cut and add
> one of these #defines.
> 
> So everyone should just think of every GUEST_FOO in there as being
> equivalent to:
>     struct xen_arch_domainconfig {
> 	//.... other stuff
>         uint64_t foo;
>     };
> i.e. passed to XEN_DOMCTL_createdomain during domain build (obviously and 
> a
> field foo in struct arch_domain where Xen stashes the value and uses that
> instead of GUEST_FOO etc).
> 
> The actual value of foo would be in tools/libx?/something.h, or decided 
> at
> runtime.
> 
> Obviously for FOO which is a static value that's a pain, hence the 
> #defines
> instead.

I forgot to also say, there are some regions which Xen doesn't actually
need to know about at all, but which are recorded in arch-arm.h so that the
complete memory map is in a single place. GUEST_GNTTAB_* and GUEST_MAGIC_*
for example fall into this category.

I think the GUEST_BAR_* actually fall into this too, since only the
toolstack needs to know those limits, and then tell Xen about specific
subsets which are mapped to specific devices etc.

Ian.