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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 6 Jan 2017, Roger Pau Monné wrote:
> > bridge. See [6] for more details.
> > 
> > XXX: I think this could be solved by using the host memory layout when
> > creating a guest with PCI devices => Detail it.
> 
> I'm not really sure I follow here, but if this write to the MSI doorbell
> doesn't go through the SMMU, and instead is handled by the bridge, isn't there
> a chance that a gust might be able to write anywhere in physical memory?
> 
> Or this only happens when a guest writes to a MSI doorbell that's trapped by
> the bridge and not forwarded anywhere else?

It only happens when a device (not a cpu) writes to the MSI doorbell.


> > So Xen needs to rely on DOM0 to discover the host bridges and notify Xen
> > with all the relevant informations. This will be done via a new hypercall
> > PHYSDEVOP_pci_host_bridge_add. The layout of the structure will be:
> > 
> > struct physdev_pci_host_bridge_add
> > {
> >     /* IN */
> >     uint16_t seg;
> >     /* Range of bus supported by the host bridge */
> >     uint8_t  bus_start;
> >     uint8_t  bus_nr;
> >     uint32_t res0;  /* Padding */
> >     /* Information about the configuration space region */
> >     uint64_t cfg_base;
> >     uint64_t cfg_size;
> > }
> 
> Why do you need to cfg_size attribute? Isn't it always going to be 4096 bytes
> in size?
> 
> If that field is removed you could use the PHYSDEVOP_pci_mmcfg_reserved
> hypercalls.
> 
> > DOM0 will issue the hypercall PHYSDEVOP_pci_host_bridge_add for each host
> > bridge available on the platform. When Xen is receiving the hypercall, the
> > the driver associated to the host bridge will be instantiated.
> > 
> > XXX: Shall we limit DOM0 the access to the configuration space from that
> > moment?
> 
> Most definitely yes, you should instantiate an emulated bridge over the real
> one, in order to proxy Dom0 accesses to the PCI configuration space. You for
> example don't want Dom0 moving the position of the BARs of PCI devices without
> Xen being aware (and properly changing the second stage translation).
> 
> > ## Discovering and register PCI
> > 
> > Similarly to x86, PCI devices will be discovered by DOM0 and register
> > using the hypercalls PHYSDEVOP_pci_add_device or 
> > PHYSDEVOP_manage_pci_add_ext.
> 
> Why do you need this? If you have access to the bridges you can scan them from
> Xen and discover the devices AFAICT.

I think the same


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

Good suggestion

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