From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH RFC 00/22] EEH Support for VFIO PCI devices on PowerKVM guest Date: Mon, 05 May 2014 13:56:28 +0200 Message-ID: <53677C6C.8060508@suse.de> References: <1399253291-3975-1-git-send-email-gwshan@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, alex.williamson@redhat.com, benh@kernel.crashing.org, aik@ozlabs.ru, qiudayu@linux.vnet.ibm.com To: Gavin Shan Return-path: Received: from cantor2.suse.de ([195.135.220.15]:40128 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756274AbaEEL4b (ORCPT ); Mon, 5 May 2014 07:56:31 -0400 In-Reply-To: <1399253291-3975-1-git-send-email-gwshan@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. 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. That way we ensure that user space device drivers have all the power over a device they need to drive it. Alex