> From: Alex Williamson
> Sent: Friday, January 26, 2024 5:20 AM
>
> On Thu, 25 Jan 2024 09:18:02 +0100
> Eric Auger <eau...@redhat.com> wrote:
>
> > Hi Vivek,
> >
> > On 1/18/24 20:20, Vivek Kasireddy wrote:
> > >
> > > + if (iommu_phys_bits && phys_bits > iommu_phys_bits) {
> > > + phys_bits = iommu_phys_bits;
> > are you allowed to change the host cpu characteristics without taking
> > care of compats for migration?
>
> Not only is migration an issue, but so is hotplug. Anything that
> aligns the VM configuration to the host is going to have migration
> issues and anything that does so conditionally based on the current set
> of attached devices will have hotplug issues.
Does it make more sense to print out a warning so it's admin to figure
out the proper phys_bits workable with the iommu restriction, instead of
forcing/hard-coding any value implicitly?
>
> It'd be more prudent to find the least common denominator under
> /sys/class/iommu/dmar*/intel-iommu/cap regardless of attached devices,
> but it still affects migration compatibility between hosts.
>
> Also note that vfio-pci can specify the device with either host= or
> sysfsdev= and with vfio cdev support and iommufd the file descriptor
> for the vfio device might be passed via SCM rights, so we may not have
> a reference to it in sysfs. The above appears to only work with the
> host= device specification. Thanks,
>
iommufd supports a IOMMUFD_CMD_GET_HW_INFO cmd which can
also report cap/ecap on intel iommu.
