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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
