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

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

Hi Roger,

On 30/05/17 08:53, Roger Pau Monné wrote:
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
available and then report it to Xen using the existing hypercall

#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.

This could be done when configuring the BARs. Today for DOM0, we rely either on trapping or XENMEM_add_to_add_physmap.

But I still don't understand why it matters so much in the design document. This is really an implementation details.

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

Why would you do DMA using BARs? I thought DMA was only to/from memory?

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.

This should work today without any knowledge of PCIs in Xen. I am not aware of any failures with the current approach implemented. If you think it does not work, then please give a concrete example.


Julien Grall

Xen-devel mailing list



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