From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uq09r-00017X-9D for qemu-devel@nongnu.org; Fri, 21 Jun 2013 08:09:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uq09q-0004WH-71 for qemu-devel@nongnu.org; Fri, 21 Jun 2013 08:09:39 -0400 Message-ID: <1371816566.3944.62.camel@pasglop> From: Benjamin Herrenschmidt Date: Fri, 21 Jun 2013 22:09:26 +1000 In-Reply-To: <87r4fvptdy.fsf@codemonkey.ws> References: <1371806575-19347-1-git-send-email-aik@ozlabs.ru> <1371806575-19347-2-git-send-email-aik@ozlabs.ru> <37E1A8FA-6BFA-48D1-AA3E-118671C8638A@suse.de> <51C4307F.7030201@ozlabs.ru> <87r4fvptdy.fsf@codemonkey.ws> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] spapr pci msi: rework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Alexey Kardashevskiy , Alexander Graf , qemu-devel@nongnu.org, Alex Williamson , qemu-ppc@nongnu.org, David Gibson On Fri, 2013-06-21 at 06:58 -0500, Anthony Liguori wrote: > > I do not understand the question, really. Here we are emulating pHyp which > > is not real hardware and never pretended to be. Our guests do not touch MSI > > records in the config space and use RTAS MSI calls instead. > > But RTAS is implemented as guest code. I suspect it's doing region > access to generate the actual MSI events. No, not really. On pHyp, RTAS just gets the list of MSIs for the slot from pHyp using private hypercalls, including the MSI address. Note that in HW the MSI address is specific to a PCI host bridge, ie, you have 6 bridges, they may all 6 provide the same addresses to the device though they decode them to different PE's (protection domains). But it doesn't matter. From a PAPR guest perspective, indeed, we don't care, *except* for a hack that went upstream in 3.10 that tries to enforce 32-bit MSIs on broken AMD video cards and makes assumptions based on the PCIe bus speed in the device-tree :-) However we shouldn't hit that. In any case, if Alexey was to actually emulate our real HW, just having the address + data is not enough to identify a specific interrupt since each PHB will have it's own domain there. Thus the host bridge must be passed down the call at the very least. >>From there, the way we internally generate and decode those address/data in qemu is of no relevance since PAPR being paravirtualized, the guest doesn't care. Ben.