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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 31 Jan 2017, Julien Grall wrote:
> > > > > By default all the PCI devices will be assigned to DOM0. So Xen would
> > > > > have
> > > > > to configure the SMMU and Interrupt Controller to allow DOM0 to use
> > > > > the PCI
> > > > > devices. As mentioned earlier, those subsystems will require the
> > > > > StreamID
> > > > > and DeviceID. Both can be deduced from the RID.
> > > > > 
> > > > > XXX: How to hide PCI devices from DOM0?
> > > > 
> > > > By adding the ACPI namespace of the device to the STAO and blocking Dom0
> > > > access to this device in the emulated bridge that Dom0 will have access
> > > > to
> > > > (returning 0xFFFF when Dom0 tries to read the vendor ID from the PCI
> > > > header).
> > > 
> > > Sorry I was not clear here. By hiding, I meant DOM0 not instantiating a
> > > driver (similarly to xen-pciback.hide). We still want DOM0 to access the
> > > PCI
> > > config space in order to reset the device. Unless you plan to import all
> > > the
> > > reset quirks in Xen?
> > 
> > I don't have a clear opinion here, and I don't know all thew details of this
> > reset hacks.
> 
> Actually I looked at the Linux code (see __pci_dev_reset in drivers/pci/pci.c)
> and there are less quirks than I expected. The list of quirks can be found in
> pci_dev_reset_methods in drivers/pci/quirks.c.
> 
> There are few way to reset a device (see __pci_dev_reset), they look all based
> on accessing the configuration space. So I guess it should be fine to import
> that in Xen. Any opinions?

I think it is a good idea: we don't want to end up with a motley
solution with bits and pieces scattered across the system. If we give
Xen ownership over PCI, it should be Xen to do device reset. Thus, it
would be OK to import those functions into the hypervisor.

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