Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-17 at 18:37 +0800, yongji xie wrote:

On 2015/12/17 4:14, Alex Williamson wrote:

quoted

On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:

quoted

Current vfio-pci implementation disallows to mmap MSI-X table in
case that user get to touch this directly.

However, EEH mechanism could ensure that a given pci device
can only shoot the MSIs assigned for its PE and guest kernel also
would not write to MSI-X table in pci_enable_msix() because
para-virtualization on PPC64 platform. So MSI-X table is safe to
access directly from the guest with EEH mechanism enabled.

The MSI-X table is paravirtualized on vfio in general and interrupt
remapping theoretically protects against errant interrupts, so why
is
this PPC64 specific?  We have the same safeguards on x86 if we want
to
decide they're sufficient.  Offhand, the only way I can think that
a
device can touch the MSI-X table is via backdoors or p2p DMA with
another device.

Maybe I didn't make my point clear. The reasons why we can mmap MSI-X
table on PPC64 are：

1. EEH mechanism could ensure that a given pci device can only shoot
the MSIs assigned for its PE. So it would not do harm to other memory
space when the guest write a garbage MSI-X address/data to the vector
table
if we passthough MSI-X tables to guest.

Interrupt remapping does the same on x86.

2. The guest kernel would not write to MSI-X table on PPC64 platform
when device drivers call pci_enable_msix() to initialize MSI-X
interrupts.

This is irrelevant to the vfio API.  vfio is a userspace driver
interface, QEMU is just one possible consumer of the interface.  Even
in the case of PPC64 & QEMU, the guest is still capable of writing to
the vector table, it just probably won't.

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,

Alex