qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 3/3] sPAPR: EEH support for VFIO PCI device


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v7 3/3] sPAPR: EEH support for VFIO PCI device
Date: Thu, 29 May 2014 00:58:10 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0


On 28.05.14 23:54, Benjamin Herrenschmidt wrote:
On Wed, 2014-05-28 at 13:24 +0200, Alexander Graf wrote:
    int (*eeh_handler)(PCIDevice *pdev, int opcode, int option);
If we need a PCI device level callback, yes.
I think a PCI device level callback is preferable regardless of whether
the current VFIO creates a PHB for a group/domain/PE or not. Emulated
devices might do differently etc..

So from the layering the way I grasped EEH works is that it basically operates on a mystical PE level. We basically have

  PHB =n=> PE =m=> Devices

One PE can contain VFIO devices that all share the same "container" and emulated devices.

What I think we need to do for emulated EEH is to implement it on a PE level. What EEH really does is that it unlinks a device's access to memory and it disallows for config space access.

Both of these operations really occur on the PE / PHB level. So we could for example have a bit in the PE that says "you're broken". When that bit is set, config space reads return -1 and writes become nops. When we enable that bit, we disable all IOMMU translations as well, so devices behind that PE become DMA incapable as well.

For the VFIO container, we have to notify it when something like this happens. So when we set the "you're broken" bit in the virtual PE, we have to notify the container to also break any real PE that VFIO devices behind that virtual PE are on. The same goes for recovery operations and so on.


Today, we don't really model multiple PEs, but assume that there's one PE per emulated PHB. So the model becomes easier in the sense that we can ignore the PHB -> PE abstraction and just maintain the code and state that the PE entity would have inside the PHB device.

Later, if we model it nicely now, it should be trivial to rip apart the PHB and PE entities and make them separate.

I hope that makes sense so far, and I hope we're all on the same page as to directions here.


Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]