[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PCI Passthrough ARM Design : Draft1
On Wed, 17 Jun 2015, Ian Campbell wrote: > On Tue, 2015-06-16 at 18:16 +0100, Stefano Stabellini wrote: > > I wrote this before reading the rest of the thread with your alternative > > suggestion. Both approaches can work, maybe it is true that having the > > guest requesting mappings is better. And we should certainly do the same > > thing for PVH and ARM guests. > > > > If we have the guest requesting the mapping, obviously the hypercall > > implementation should check whether mapping the memory region has been > > previously allowed by the toolstack, that should still call > > xc_domain_iomem_permission. > > Whoever makes the initial decision/setup we still need to decide what to > do about reads and writes to the device's BAR registers. Who deals with > these and how, and if writes are allowed and if so how is this then > reflected in the guest p2m. > > I would very much prefer ARM and x86 PVH to use the same approach to > this. > > For x86 HVM I believe QEMU takes care of this, by emulating the > reads/writes to CFG space and making hypercalls (domctls?) to update the > p2m. There is no QEMU to do this in the ARM or x86 PVH cases. > > For x86 PV I believe pciback deals with the register reads/writes but it > doesn't need to do anything wrt the p2m because that is a guest internal > construct. This obviously doesn't apply to ARM or x86 PVH either since > the p2m is managed by Xen in both those cases. > > So it seems that neither of the existing solutions are a good match for > either ARM or x86 PVH. > > _If_ it were permissible to implement all BAR registers as r/o then this > might simplify things, however I suspect this is not something we can > get away with in the general case (i.e. a driver for a given PCI device > _knows_ that BAR<N> is writeable...). > > So I think we do need to allow guest writes to the BAR registers. I > think it would be a bit strange (or even open potentially subtle > (security?) issues) to require the guest to write the BAR register and > to update the p2m to match as well. Why would it be a security risk? I don't think it is important that the interface between pcifront and pciback refrects the hardware interface. But it is important that the interface is documented and complies to the expected behaviour. I think that if we go with XENMEM_add_to_physmap_range, it would be OK for pcifront to both write to the vBAR (actually writing to the ring to pciback), then call XENMEM_add_to_physmap_range. On the other hand, if we go with XEN_DOMCTL_memory_mapping, I would make the virtual BAR read-only, that is less preferable but still acceptable, as long as we document it. > So I think updates to the BAR need to be reflected in the p2m too by > whichever entity is emulating those reads/writes. I wouldn't make this a requirement. > QEMU (or another daemon) is not really an option IMHO. I agree! > Which leaves us with either Xen doing trap and emulate or pciback > dealing with this via the pciif.h cfg space access stuff. I've a slight > preference for the latter since I think both ARM and x86 PVH are > planning to use pcifront/pciback already. I also agree that between these two options, pciback is better. But XENMEM_add_to_physmap_range is still the simplest. > Which leaves us with a requirement for the backend to be able to update > the p2m, which in turn leads to a need for an interface available to the > dom0 kernel (which the existing domctl is not). > > There will also need to be a mechanism to expose a suitable MMIO hole to > pcifront. On x86 this would be via the machine memory map, I think, but > on ARM we may need something else, perhaps a xenstore key associated > with the pci bus entry in xenstore? Can't we just let the guest kernel find an address range large enough that is not normal memory? > That's for guests, for dom0 Xen also need to be aware of changes to the > BAR registers of the real physical devices since it needs to know the > real hardware values in order to point guest p2m mappings at them. I think that in the Dom0 case, we want to map them 1:1. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |