Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, May 29, 2017 at 07:14:55PM +0100, Julien Grall wrote:
> On 05/29/2017 03:30 AM, Manish Jaggi wrote:
> > On 5/26/2017 10:44 PM, Julien Grall wrote:
[...]
> > > ## Discovering and registering PCI devices
> > > 
> > > The hardware domain will scan the host bridge to find the list of PCI
> > > devices
> > > available and then report it to Xen using the existing hypercall
> > > PHYSDEV_pci_device_add:
> > > 
> > > #define XEN_PCI_DEV_EXTFN   0x1
> > > #define XEN_PCI_DEV_VIRTFN  0x2
> > > #define XEN_PCI_DEV_PXM     0x3
> > > 
> > > struct physdev_pci_device_add {
> > >      /* IN */
> > >      uint16_t    seg;
> > >      uint8_t     bus;
> > >      uint8_t     devfn;
> > >      uint32_t    flags;
> > >      struct {
> > >          uint8_t bus;
> > >          uint8_t devfn;
> > >      } physfn;
> > >      /*
> > >       * Optional parameters array.
> > >       * First element ([0]) is PXM domain associated with the device (if
> > >       * XEN_PCI_DEV_PXM is set)
> > >       */
> > >      uint32_t optarr[0];
> > > }
> > For mapping the MMIO space of the device in Stage2, we need to add
> > support in Xen / via a map hypercall in linux/drivers/xen/pci.c
> 
> Mapping MMIO space in stage-2 is not PCI specific and already addressed in
> Xen 4.9 (see commit 80f9c31 "xen/arm: acpi: Map MMIO on fault in stage-2
> page table for the hardware domain"). So I don't understand why we should
> care about that here...

I'm not sure what Manish means, but you should map the BARs of the
device when adding it to a domain. Doing mapping on faults will work
with CPU accesses, but it's not going to work with SMMU faults, those are
asynchronous, and I don't think you can guarantee that the CPU is
always going to access the BARs before doing any DMA transactions to
them.

Note that Xen can also scan the bridge by itself and add the devices,
I'm not sure you need the PHYSDEV_pci_device_add hypercall.

Roger.

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