Thread (32 messages) 32 messages, 4 authors, 2014-06-03

Re: [PATCH 3/4] drivers/vfio: New IOCTL command VFIO_EEH_INFO

From: Alexander Graf <hidden>
Date: 2014-05-20 11:44:27

On 20.05.14 13:40, Gavin Shan wrote:
On Tue, May 20, 2014 at 01:28:40PM +0200, Alexander Graf wrote:
quoted
On 20.05.14 13:21, Alexander Graf wrote:
quoted
On 20.05.14 10:30, Gavin Shan wrote:
quoted
The patch adds new IOCTL command VFIO_EEH_OP to VFIO PCI device
to support EEH functionality for PCI devices, which have been
passed from host to guest via VFIO.

Signed-off-by: Gavin Shan <redacted>
---
  arch/powerpc/platforms/powernv/Makefile   |   1 +
  arch/powerpc/platforms/powernv/eeh-vfio.c | 445
++++++++++++++++++++++++++++++
  drivers/vfio/pci/vfio_pci.c               |  24 +-
  drivers/vfio/pci/vfio_pci_private.h       |  16 ++
  include/uapi/linux/vfio.h                 |  43 +++
  5 files changed, 523 insertions(+), 6 deletions(-)
  create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
Why doesn't this code live inside the vfio module? If I don't load
the vfio module, I don't need that code to waste memory in my
kernel, no?
Yes, It saves some memory.
quoted
So I think from a modeling point of view, you want VFIO code that
calls reasonably generic helpers inside the kernel to deal with
errors.

The "generic helpers" don't have anything to do with VFIO. Everything
that interfaces via ioctls with user space is 100% VFIO code.

The latter should be tristate inside vfio.ko, the former can be =y.
The main reason I put eeh-vfio.c to arch/powerpc/platforms/powernv/ is
the source file needs access data structures (struct pnv_phb) defined
in "pci.h" under that directory.
Then create a good in-kernel framework from that directory and make use 
of it from the VFIO code :). But please don't mesh together VFIO, 
powernv EEH handling and RTAS.


Alex
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help