From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq3mn-000197-0y for qemu-devel@nongnu.org; Mon, 09 Dec 2013 11:34:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq3ma-0007cV-Ok for qemu-devel@nongnu.org; Mon, 09 Dec 2013 11:34:20 -0500 Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:52831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq3ma-0007c3-HC for qemu-devel@nongnu.org; Mon, 09 Dec 2013 11:34:08 -0500 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Dec 2013 16:34:05 -0000 From: Greg Kurz Date: Mon, 09 Dec 2013 17:33:57 +0100 Message-ID: <20131209163357.14448.60087.stgit@bahia.local> In-Reply-To: <1373951995-9866-1-git-send-email-aik@ozlabs.ru> References: <1373951995-9866-1-git-send-email-aik@ozlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [PATCH] spapr-pci: remove io ports workaround List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aik@ozlabs.ru, agraf@suse.de, qemu-ppc@nongnu.org, anthony@codemonkey.ws, pbonzini@redhat.com, paulus@samba.org, david@gibson.dropbear.id.au In the past, IO space could not be mapped into the memory address space so we introduced a workaround for that. Nowadays it does not look necessary so we can remove the workaround and make sPAPR PCI configuration simplier. This workaround has also an evil side effect with virtio devices: because all PHBs have their .io region at the same address, the devices get mapped in the .io-alias region of every PHB (AKA. mapped multiple times). This breaks the ioeventfd feature and causes qemu to abort() when running with KVM and asking for more than one PHB: $ qemu-system-ppc64 -machine type=pseries,accel=kvm -smp 1 -m 4G \ -hda /local/greg/images/fedora-be.qcow2 \ -device virtio-9p-pci,fsdev=fsdev0,mount_tag=share,bus=pci,ioeventfd=on \ -fsdev local,security_model=none,id=fsdev0,path=$HOME/share1 \ -device spapr-pci-host-bridge,index=15 kvm_mem_ioeventfd_add: error adding ioeventfd: File exists Aborted This will prevent to use virtio and VFIO passthrough at the same time, since VFIO needs a dedicated PHB to work on ppc. Signed-off-by: Alexey Kardashevskiy Signed-off-by: Greg Kurz --- hw/ppc/spapr_pci.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index 7763149..7d29431 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -564,23 +564,14 @@ static int spapr_phb_init(SysBusDevice *s) memory_region_add_subregion(get_system_memory(), sphb->mem_win_addr, &sphb->memwindow); - /* On ppc, we only have MMIO no specific IO space from the CPU - * perspective. In theory we ought to be able to embed the PCI IO - * memory region direction in the system memory space. However, - * if any of the IO BAR subregions use the old_portio mechanism, - * that won't be processed properly unless accessed from the - * system io address space. This hack to bounce things via - * system_io works around the problem until all the users of - * old_portion are updated */ + /* Initialize IO regions */ sprintf(namebuf, "%s.io", sphb->dtbusname); memory_region_init(&sphb->iospace, OBJECT(sphb), namebuf, SPAPR_PCI_IO_WIN_SIZE); - /* FIXME: fix to support multiple PHBs */ - memory_region_add_subregion(get_system_io(), 0, &sphb->iospace); sprintf(namebuf, "%s.io-alias", sphb->dtbusname); memory_region_init_alias(&sphb->iowindow, OBJECT(sphb), namebuf, - get_system_io(), 0, SPAPR_PCI_IO_WIN_SIZE); + &sphb->iospace, 0, SPAPR_PCI_IO_WIN_SIZE); memory_region_add_subregion(get_system_memory(), sphb->io_win_addr, &sphb->iowindow); /*