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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 1 Feb 2017, Roger Pau Monné wrote:
> On Tue, Jan 31, 2017 at 02:03:16PM -0800, Stefano Stabellini wrote:
> > 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.
> 
> +1. Then AFAICT PCI-passthrough would be completely handled by Xen, without
> needing any Dom0 kernel interaction? (apart from the toolstack, of course)

indeed

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