Hi Alex, > -----Original Message----- > From: Shameerali Kolothum Thodi > Sent: Monday, November 20, 2017 4:31 PM > To: 'Alex Williamson' <alex.william...@redhat.com> > Cc: eric.au...@redhat.com; Zhuyijun <zhuyi...@huawei.com>; qemu- > a...@nongnu.org; qemu-devel@nongnu.org; peter.mayd...@linaro.org; > Zhaoshenglong <zhaoshengl...@huawei.com>; Linuxarm > <linux...@huawei.com> > Subject: RE: [Qemu-devel] [RFC 1/5] hw/vfio: Add function for getting > reserved_region of device iommu group [...] > > > > And sysfs is a good interface if the user wants to use it to > > > > configure the VM in a way that's compatible with a device. For > > > > instance, in your case, a user could evaluate these reserved > > > > regions across all devices in a system, or even across an entire > > > > cluster, and instantiate the VM with a memory map compatible with > > > > hotplugging any of those evaluated devices (QEMU implementation of > allowing the user to do this TBD). > > > > Having the vfio device evaluate these reserved regions only helps > > > > in the cold-plug case. So the proposed solution is limited in > > > > scope and doesn't address similar needs on other platforms. There > > > > is value to verifying that a device's IOVA space is compatible > > > > with a VM memory map and modifying the memory map on cold-plug or > > > > rejecting the device on hot-plug, but isn't that why we have an > > > > ioctl within vfio to expose information about the IOMMU? Why take > > > > the path of allowing QEMU to rummage through sysfs files outside > > > > of vfio, implying additional security and access concerns, rather > > > > than filling the gap within the vifo API? > > > > > > Thanks Alex for the explanation. > > > > > > I came across this patch[1] from Eric where he introduced the IOCTL > > interface to > > > retrieve the reserved regions. It looks like this can be reworked to > > accommodate > > > the above requirement. > > > > I don't think we need a new ioctl for this, nor do I think that > > describing the holes is the correct approach. The existing > > VFIO_IOMMU_GET_INFO ioctl can be extended to support capability > > chains, as we've done for VFIO_DEVICE_GET_REGION_INFO. > > Right, as far as I can see the above mentioned patch is doing exactly the > same, > extending the VFIO_IOMMU_GET_INFO ioctl with capability chain. > > > IMO, we should try to > > describe the available fixed IOVA regions which are available for > > mapping rather than describing various holes within the address space > > which are unavailable. The latter method always fails to describe the > > end of the mappable IOVA space and gets bogged down in trying to > > classify the types of holes that might exist. Thanks, >
I was going through this and noticed that it is possible to have multiple iommu domains associated with a container. If that's true, is it safe to make the assumption that all the domains will have the same iova geometry or not? Thanks, Shameer
