Re: [PATCH RFC 00/22] EEH Support for VFIO PCI devices on PowerKVM guest

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

 




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.



Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux