[RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported
Benjamin Herrenschmidt
benh at kernel.crashing.org
Fri Dec 18 09:48:21 AEDT 2015
On Thu, 2015-12-17 at 14:41 -0700, Alex Williamson wrote:
> > So I think it is safe to mmap/passthrough MSI-X table on PPC64
> > platform.
> > And I'm not sure whether other architectures can ensure these two
> > points.
>
> There is another consideration, which is the API exposed to the user.
> vfio currently enforces interrupt setup through ioctls by making the
> PCI mechanisms for interrupt programming inaccessible through the
> device regions. Ignoring that you are only focused on PPC64 with QEMU,
> does it make sense for the vfio API to allow a user to manipulate
> interrupt programming in a way that not only will not work, but in a
> way that we expect to fail and require error isolation to recover from?
> I can't say I'm fully convinced that a footnote in the documentation
> is sufficient for that. Thanks,
Well, one could argue that the "isolation" provided by qemu here is
fairly weak anyway ;-)
I mean. .. how do you know the device doesn't have a backdoor path into
that table via some other MMIO registers anyway ?
In any case, the HW isolation on platforms like pseries means that the
worst the guest can do si shoot itself in the foot. Big deal. On the
other hand, not bothering with intercepting the table has benefits,
such as reducing the memory region clutter, but also removing all the
massive performacne problems we see because adapters have critical
registers in the same 64K page as the MSI-X table.
So I don't think there is any question here that we *need* that
functionality in power. The filtering of the table by Qemu doesn't
provide any practical benefit, it just gets in the way.
Cheers,
Ben.
More information about the Linuxppc-dev
mailing list