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. 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. Please cc me on vfio related patches. Thanks, Alex
