From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Wed, 28 May 2014 23:18:45 +0000 Subject: Re: [PATCH v7 3/3] drivers/vfio: EEH support for VFIO PCI device Message-Id: <1401319125.8262.34.camel@pasglop> List-Id: References: <1401180052-6060-1-git-send-email-gwshan@linux.vnet.ibm.com> <1401180052-6060-4-git-send-email-gwshan@linux.vnet.ibm.com> <1401214527.3289.611.camel@ul30vt.home> <20140528005532.GA5528@shangw> <5385CB6F.50300@suse.de> <20140528124947.GA19346@shangw> <1401314311.8262.26.camel@pasglop> <53866747.50703@suse.de> In-Reply-To: <53866747.50703@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: aik@ozlabs.ru, Gavin Shan , kvm-ppc@vger.kernel.org, Alex Williamson , qiudayu@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org On Thu, 2014-05-29 at 00:46 +0200, Alexander Graf wrote: > I don't think so :). In QEMU the PHB emulation would have to notify the > "container" (IOMMU emulation layer -> PE) that a PE operation happened. > It's that emulation code's responsibility to broadcast operations across > its own emulated operations (recover config space access, reconfigure > BARs, etc) and the VFIO PE operations. > > So from a kernel interface point of view, I think leaving out any > address information is the right way to go. Whether we managed to get > all QEMU internal interfaces modeled correctly yet has to be seen on the > next patch set revision :). For a kernel interface I absolutely agree, all we care about is the group fd. >From a qemu internal, I suppose it makes things easier to operate at the PHB level for now and we can revisit later if the need arises. Cheers, Ben.