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

Re: PCI devices passthrough on Arm design proposal



Hi,

On 17/07/2020 14:59, Jan Beulich wrote:
On 17.07.2020 15:50, Julien Grall wrote:
(Resending to the correct ML)
On 17/07/2020 14:23, Julien Grall wrote:
On 16/07/2020 18:02, Rahul Singh wrote:
# Discovering PCI devices:

PCI-PCIe enumeration is a process of detecting devices connected to
its host. It is the responsibility of the hardware domain or boot
firmware to do the PCI enumeration and configure the BAR, PCI
capabilities, and MSI/MSI-X configuration.

PCI-PCIe enumeration in XEN is not feasible for the configuration part
as it would require a lot of code inside Xen which would require a lot
of maintenance. Added to this many platforms require some quirks in
that part of the PCI code which would greatly improve Xen complexity.
Once hardware domain enumerates the device then it will communicate to
XEN via the below hypercall.

#define PHYSDEVOP_pci_device_add        25
struct physdev_pci_device_add {
      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[XEN_FLEX_ARRAY_DIM];
      };

As the hypercall argument has the PCI segment number, XEN will access
the PCI config space based on this segment number and find the
host-bridge corresponding to this segment number. At this stage host
bridge is fully initialized so there will be no issue to access the
config space.

XEN will add the PCI devices in the linked list maintain in XEN using
the function pci_add_device(). XEN will be aware of all the PCI
devices on the system and all the device will be added to the hardware
domain.
I understand this what x86 does. However, may I ask why we would want it
for Arm?

Isn't it the normal thing to follow what there is, and instead provide
reasons why a different approach is to be followed?

Not all the decision on x86 have been great and this is the opportunity to make it better rather than blindly follow. For instance, platform devices were are not assigned (back) to dom0 by default. Thanks to this decision, we were not affected by XSA-306.

Personally I'd much
prefer if we didn't have two fundamentally different PCI implementations
in the tree. Perhaps some of what Arm wants or needs can actually
benefit x86 as well, but this requires sufficiently much code sharing
then.

Well, it would be nice to have similar implementations. But at the same time, we have different constraint. For instance, dom0 may disappear in the future on Arm.

Cheers,

--
Julien Grall



 


Rackspace

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