From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsXU2-0007pi-2k for qemu-devel@nongnu.org; Thu, 05 Jun 2014 09:13:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsXTt-0001HM-Hh for qemu-devel@nongnu.org; Thu, 05 Jun 2014 09:13:30 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:43016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsXTt-0001H2-Cl for qemu-devel@nongnu.org; Thu, 05 Jun 2014 09:13:21 -0400 Received: by mail-pb0-f46.google.com with SMTP id rq2so1099432pbb.19 for ; Thu, 05 Jun 2014 06:13:20 -0700 (PDT) Message-ID: <53906CEB.9060309@ozlabs.ru> Date: Thu, 05 Jun 2014 23:13:15 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1401951221-32613-1-git-send-email-gwshan@linux.vnet.ibm.com> <1401951221-32613-5-git-send-email-gwshan@linux.vnet.ibm.com> <539069E1.8040309@suse.de> In-Reply-To: <539069E1.8040309@suse.de> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 4/4] sPAPR: Implement sPAPRPHBClass::eeh_handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , Gavin Shan , qemu-ppc@nongnu.org Cc: alex.williamson@redhat.com, qiudayu@linux.vnet.ibm.com, qemu-devel@nongnu.org On 06/05/2014 11:00 PM, Alexander Graf wrote: > > On 05.06.14 08:53, Gavin Shan wrote: >> The patch implements sPAPRPHBClass::eeh_handler so that the >> EEH RTAS requests can be routed to VFIO for further handling. >> >> Signed-off-by: Gavin Shan > > Just to make sure I grasp this correctly. > > We have PHBs that are VFIO PHBs and PHBs that are emulation PHBs. Emulation > PHBs can only have emulated devices attached. VFIO PHBs can only have a > single IOMMU group's devices attached each. A container can not span 2 > different VFIO PHBs. > > Is this correct? Yes, this is correct. PHBs are too cheap on SPAPR to think of any additional complication here :) > If not the code below needs to take care of any > abstraction we have in between and maybe limit scope a bit to make sure the > guest doesn't kill devices on other PHBs :). -- Alexey