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@lists.xen.org
https://lists.xen.org/xen-devel
