[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PCI Passthrough Design - Draft 3



On Wed, Aug 12, 2015 at 09:56:41AM +0100, Ian Campbell wrote:
> On Tue, 2015-08-11 at 16:34 -0400, Konrad Rzeszutek Wilk wrote:
> > 
> > > 2.2    PHYSDEVOP_pci_host_bridge_add hypercall
> > > ----------------------------------------------
> > > Xen code accesses PCI configuration space based on the sbdf received from
> > > the
> > > guest. The order in which the pci device tree node appear may not be the
> > > same
> > > order of device enumeration in dom0. Thus there needs to be a mechanism to
> > > bind
> > > the segment number assigned by dom0 to the pci host controller. The
> > > hypercall
> > > is introduced:
> > 
> > Why can't we extend the existing hypercall to have the segment value?
> > 
> > Oh wait, PHYSDEVOP_manage_pci_add_ext does it already!
> > 
> > And have the hypercall (and Xen) be able to deal with introduction of PCI
> > devices that are out of sync?
> > 
> > Maybe I am confused but aren't PCI host controllers also 'uploaded' to
> > Xen?
> 
> The issue is that Dom0 and Xen need to agree on a common numbering space
> for the "PCI domain" AKA "segment", which is really just a software concept
> i.e. on ARM Linux just makes them up (on x86 I believe they come from some
> firmware table so Xen and Dom0 "agree" to both use that).

Doesn't the PCI domain or segments have an notion of which PCI devices are
underneath it? Or vice-verse - PCI devices know what their segment (or domain) 
is?

> 
> Ian.
> 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.