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: Alex Williamson [mailto:address@hidden
> Sent: Tuesday, November 14, 2017 3:48 PM
> To: Zhuyijun <address@hidden>
> Cc: address@hidden; address@hidden;
> address@hidden; address@hidden; Shameerali Kolothum
> Thodi <address@hidden>; Zhaoshenglong
> <address@hidden>
> 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
> <address@hidden> wrote:
> 
> > From: Zhu Yijun <address@hidden>
> >
> > 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 <address@hidden>
> > ---
> >  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