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

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

On Thu, 2015-08-13 at 09:29 -0600, Jan Beulich wrote:

A bunch of your questions seem to be about things which have been discussed
at length in previous postings, it's probably worth reviewing some of those
discussions.

> > 
> >   /* For 32bit BARs*/
> >   #define GUEST_BAR_BASE_32 <<>>
> >   #define GUEST_BAR_SIZE_32 <<>>
> > 
> >   /* For 64bit BARs*/
> >   #define GUEST_BAR_BASE_64 <<>>
> >   #define GUEST_BAR_SIZE_64 <<>>
> 
> This sounds like you want to use a pair of fixed (forever, since putting
> it in the ABI) ranges - is that really a good idea? Wouldn't it be possible
> (and necessary when assigning many or large devices) to establish
> these ranges dynamically?

The guest physical address space layout is explicitly not an ABI on ARM.
The relevant bits of arch-arm.h have the appropriate tools-and-xen-only
ifdefs.

> 
[...]
> Furthermore OSes can generally reassign BARs as they see fit (as
> long as the chosen addresses don't collide with anything else).

Not with PV pcifront/back based setups, the BARs are fixed then I believe,
even for x86/PV. That model is being followed on ARM too.

We don't want to involve QEMU just to emulate this sort of thing, and nor
do we really want to add such functionality to pciback.


> But I wonder in general why this would need to be done through
> xenstore: pciback knows the real BAR base, and with the help of
> the hypervisor it ought to be able to also know the corresponding
> guest address.

How? Previously adding a new hypercall was proposed for this, I didn't like
that approach because it added a new frozen ABI to the hypercall interface
and IMHO the tools is the right place to have the address space layout
stuff anyway.


> >   Since there is only one pci-frontend bus in domU, s:b:d.f is 0:0:d.f
> >   It is proposed in this design document that the df generation be done 
> > by
> >   toolstack and the xenstore keys be created by toolstack.
> > 
> >   Folowing guest_sbdf generation the domctl to assign the device is 
> > invoked.
> >   This hypercall is updated to include *guest_sbdf*. Xen ITS driver can 
> > 
> > store
> >   this mapping domID: guest_sbdf: machine_sbdf and can be used later.
> 
> Mind explaining why the hypervisor needs to know about the guest
> topology? Is that because you want to continue to not involve qemu
> in any of the emulation?

Some virtualsed hardware (i.e. the interrupt translation unit) take device
-ids which are derived from the SBDF, since Xen deals with configuring that
h/w it needs to know the guest's SBDF.

Ian.