Re: [Qemu-arm] [Qemu-devel] [RFC 1/5] hw/vfio: Add function for getting reserved_region of device iommu group

[Shameerali Kolothum Thodi]

Hi Alex,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Monday, November 20, 2017 4:31 PM
> To: 'Alex Williamson' <address@hidden>
> Cc: address@hidden; Zhuyijun <address@hidden>; qemu-
> address@hidden; address@hidden; address@hidden;
> Zhaoshenglong <address@hidden>; Linuxarm
> <address@hidden>
> 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