[PATCH RFC 00/22] EEH Support for VFIO PCI devices on PowerKVM guest
agraf at suse.de
Tue May 6 16:56:35 EST 2014
On 06.05.14 06:26, Gavin Shan wrote:
> On Mon, May 05, 2014 at 08:00:12AM -0600, Alex Williamson wrote:
>> On Mon, 2014-05-05 at 13:56 +0200, Alexander Graf wrote:
>>> On 05/05/2014 03:27 AM, Gavin Shan wrote:
>>>> The series of patches intends to support EEH for PCI devices, which have been
>>>> passed through to PowerKVM based guest via VFIO. The implementation is
>>>> straightforward based on the issues or problems we have to resolve to support
>>>> EEH for PowerKVM based guest.
>>>> - Emulation for EEH RTAS requests. Thanksfully, we already have infrastructure
>>>> to emulate XICS. Without introducing new mechanism, we just extend that
>>>> existing infrastructure to support EEH RTAS emulation. EEH RTAS requests
>>>> initiated from guest are posted to host where the requests get handled or
>>>> delivered to underly firmware for further handling. For that, the host kerenl
>>>> has to maintain the PCI address (host domain/bus/slot/function to guest's
>>>> PHB BUID/bus/slot/function) mapping via KVM VFIO device. The address mapping
>>>> will be built when initializing VFIO device in QEMU and destroied when the
>>>> VFIO device in QEMU is going to offline, or VM is destroy.
>>> Do you also expose all those interfaces to user space? VFIO is as much
>>> about user space device drivers as it is about device assignment.
> Yep, all the interfaces are exported to user space.
>>> I would like to first see an implementation that doesn't touch KVM
>>> emulation code at all but instead routes everything through QEMU. As a
>>> second step we can then accelerate performance critical paths inside of KVM.
> Ok. I'll change the implementation. However, the QEMU still has to
> poll/push information from/to host kerenl. So the best place for that
> would be tce_iommu_driver_ops::ioctl as EEH is Power specific feature.
> For the error injection, I guess I have to put the logic token management
> into QEMU and error injection request will be handled by QEMU and then
> routed to host kernel via additional syscall as we did for pSeries.
Yes, start off without in-kernel XICS so everything simply lives in
QEMU. Then add callbacks into the in-kernel XICS to inject these
interrupts if we don't have wide enough interfaces already.
More information about the Linuxppc-dev