Hi Alex, > -----Original Message----- > From: Alex Williamson [mailto:[email protected]] > Sent: Tuesday, November 14, 2017 3:48 PM > To: Zhuyijun <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; Shameerali Kolothum > Thodi <[email protected]>; Zhaoshenglong > <[email protected]> > Subject: Re: [Qemu-devel] [RFC 1/5] hw/vfio: Add function for getting > reserved_region of device iommu group > > On Tue, 14 Nov 2017 09:15:50 +0800 > <[email protected]> wrote: > > > From: Zhu Yijun <[email protected]> > > > > With kernel 4.11, iommu/smmu will populate the MSI IOVA reserved > > window and PCI reserved window which has to be excluded from Guest iova > allocations. > > > > However, If it falls within the Qemu default virtual memory address > > space, then reserved regions may get allocated for a Guest VF DMA iova > > and it will fail. > > > > So get those reserved regions in this patch and create some holes in > > the Qemu ram address in next patchset. > > > > Signed-off-by: Zhu Yijun <[email protected]> > > --- > > hw/vfio/common.c | 67 > +++++++++++++++++++++++++++++++++++++++++++ > > hw/vfio/pci.c | 2 ++ > > hw/vfio/platform.c | 2 ++ > > include/exec/memory.h | 7 +++++ > > include/hw/vfio/vfio-common.h | 3 ++ > > 5 files changed, 81 insertions(+) > > I generally prefer the vfio interface to be more self sufficient, if there are > regions the IOMMU cannot map, we should be describing those via capabilities > on the container through the vfio interface. If we're just scraping together > things from sysfs, the user can just as easily do that and provide an explicit > memory map for the VM taking the devices into account.
Ok. I was under the impression that the purpose of introducing the /sys/kernel/iommu_groups/reserved_regions was to get the IOVA regions that are reserved(MSI or non-mappable) for Qemu or other apps to make use of. I think this was introduced as part of the "KVM/MSI passthrough support on ARM" patch series. And if I remember correctly, Eric had an approach where the user space can retrieve all the reserved regions through the VFIO_IOMMU_GET_INFO ioctl and later this idea was replaced with the sysfs interface. May be I am missing something here. > Of course having a > device associated with a restricted memory map that conflicts with the default > memory map for the VM implies that you can never support hot-add of such > devices. True. Hot-add and migration will have issues on these platforms. Thanks, Shameer
