On Sun, Dec 12, 2021 at 08:44:46AM +0200, Mika Penttilä wrote: > > /* > > * The MSIX mappable capability informs that MSIX data of a BAR can be > > mmapped > > * which allows direct access to non-MSIX registers which happened to be > > within > > * the same system page. > > * > > * Even though the userspace gets direct access to the MSIX data, the > > existing > > * VFIO_DEVICE_SET_IRQS interface must still be used for MSIX > > configuration. > > */ > > #define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3 > > > > IIRC this was introduced for PPC when a device has MSI-X in the same BAR as > > other MMIO registers. Trapping MSI-X leads to performance downgrade on > > accesses to adjacent registers. MSI-X can be mapped by userspace because > > PPC already uses a hypercall mechanism for interrupt. Though unclear about > > the detail it sounds a similar usage as proposed here. > > > > Thanks > > Kevin > > I see VFIO_REGION_INFO_CAP_MSIX_MAPPABLE is always set so if msix table is > in its own bar, qemu never traps/emulates the access.
It is some backwards compat, the kernel always sets it to indicate a new kernel, that doesn't mean qemu doesn't trap. As the comment says, ""VFIO_DEVICE_SET_IRQS interface must still be used for MSIX configuration"" so there is no way qemu can meet that without either trapping the MSI page or using a special hypercall (ppc) Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu