Hi Alex, > -----Original Message----- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Tuesday, November 14, 2017 3:48 PM > To: Zhuyijun <zhuyi...@huawei.com> > Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; > eric.au...@redhat.com; peter.mayd...@linaro.org; Shameerali Kolothum > Thodi <shameerali.kolothum.th...@huawei.com>; Zhaoshenglong > <zhaoshengl...@huawei.com> > 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 > <zhuyi...@huawei.com> wrote: > > > From: Zhu Yijun <zhuyi...@huawei.com> > > > > 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 <zhuyi...@huawei.com> > > --- > > 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
