> From: Robin Murphy [mailto:robin.murphy@xxxxxxx] > Sent: Wednesday, March 21, 2018 10:24 PM > > On 21/03/18 13:14, Jean-Philippe Brucker wrote: > > On 21/03/18 06:43, Tian, Kevin wrote: > > [...] > >>> + > >>> +#include <uapi/linux/virtio_iommu.h> > >>> + > >>> +#define MSI_IOVA_BASE 0x8000000 > >>> +#define MSI_IOVA_LENGTH 0x100000 > >> > >> this is ARM specific, and according to virtio-iommu spec isn't it > >> better probed on the endpoint instead of hard-coding here? > > > > These values are arbitrary, not really ARM-specific even if ARM is the > > only user yet: we're just reserving a random IOVA region for mapping > MSIs. > > It is hard-coded because of the way iommu-dma.c works, but I don't > quite > > remember why that allocation isn't dynamic. > > The host kernel needs to have *some* MSI region in place before the > guest can start configuring interrupts, otherwise it won't know what > address to give to the underlying hardware. However, as soon as the host > kernel has picked a region, host userspace needs to know that it can no > longer use addresses in that region for DMA-able guest memory. It's a > lot easier when the address is fixed in hardware and the host userspace > will never be stupid enough to try and VFIO_IOMMU_DMA_MAP it, but in > the > more general case where MSI writes undergo IOMMU address translation > so > it's an arbitrary IOVA, this has the potential to conflict with stuff > like guest memory hotplug. > > What we currently have is just the simplest option, with the host kernel > just picking something up-front and pretending to host userspace that > it's a fixed hardware address. There's certainly scope for it to be a > bit more dynamic in the sense of adding an interface to let userspace > move it around (before attaching any devices, at least), but I don't > think it's feasible for the host kernel to second-guess userspace enough > to make it entirely transparent like it is in the DMA API domain case. > > Of course, that's all assuming the host itself is using a virtio-iommu > (e.g. in a nested virt or emulation scenario). When it's purely within a > guest then an MSI reservation shouldn't matter so much, since the guest > won't be anywhere near the real hardware configuration anyway. > > Robin. Curious since anyway we are defining a new iommu architecture is it possible to avoid those ARM-specific burden completely? Thanks Kevin
