From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxWhZ-0003z2-Nb for qemu-devel@nongnu.org; Fri, 21 Oct 2016 06:05:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxWhW-0000kH-HI for qemu-devel@nongnu.org; Fri, 21 Oct 2016 06:05:25 -0400 Received: from 3.mo7.mail-out.ovh.net ([46.105.34.113]:59104) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxWhW-0000jy-BH for qemu-devel@nongnu.org; Fri, 21 Oct 2016 06:05:22 -0400 Received: from player694.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 1036BDFFE for ; Fri, 21 Oct 2016 12:05:20 +0200 (CEST) Date: Fri, 21 Oct 2016 12:05:06 +0200 From: Greg Kurz Message-ID: <20161021120506.659ad412@bahia> In-Reply-To: <1477012792-3326-5-git-send-email-david@gibson.dropbear.id.au> References: <1477012792-3326-1-git-send-email-david@gibson.dropbear.id.au> <1477012792-3326-5-git-send-email-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv4 04/11] libqos: Better handling of PCI legacy IO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , aik@ozlabs.ru Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, lvivier@redhat.com, agraf@suse.de, stefanha@redhat.com, mst@redhat.com, mdroth@linux.vnet.ibm.com, thuth@redhat.com On Fri, 21 Oct 2016 12:19:45 +1100 David Gibson wrote: > The usual model for PCI IO with libqos is to use qpci_iomap() to map a > specific BAR for a PCI device, then perform IOs within that BAR using > qpci_io_{read,write}*(). > > However, certain devices also have legacy PCI IO. In this case, instead of > (or as well as) being accessed via PCI BARs, the device can be accessed > via certain well-known, fixed addresses in PCI IO space. > > Two existing tests use legacy PCI IO, and take different flawed approaches > to it: > * tco-test manually constructs a tco_io_base value instead of calling > qpci_iomap(), which assumes internal knowledge of the structure of > the value it shouldn't have > * ide-test uses direct in*() and out*() calls instead of using > qpci_io_*() accessors, meaning it's not portable to non-x86 machine > types. > > This patch implements a new qpci_iomap_legacy() interface which gets a > handle in the same format as qpci_iomap() but refers to a region in > the legacy PIO space. For a device which has the same registers > available both in a BAR and in legacy space (quite common), this > allows the same test code to test both options with just a different > iomap() at the beginning. > > Signed-off-by: David Gibson > Reviewed-by: Laurent Vivier > --- > tests/libqos/pci.c | 5 +++++ > tests/libqos/pci.h | 1 + > 2 files changed, 6 insertions(+) > > diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c > index bf1c532..98a2e56 100644 > --- a/tests/libqos/pci.c > +++ b/tests/libqos/pci.c > @@ -350,6 +350,11 @@ void qpci_iounmap(QPCIDevice *dev, void *data) > /* FIXME */ > } > > +void *qpci_legacy_iomap(QPCIDevice *dev, uint16_t addr) > +{ > + return (void *)(uintptr_t)addr; > +} > + Since both tco-test and ide-test are hardcoded for x86 machine types, is it right for this implementation to sit in common PCI code instead of the PC specific one ? > void qpci_plug_device_test(const char *driver, const char *id, > uint8_t slot, const char *opts) > { > diff --git a/tests/libqos/pci.h b/tests/libqos/pci.h > index f6f916d..b6f855e 100644 > --- a/tests/libqos/pci.h > +++ b/tests/libqos/pci.h > @@ -94,6 +94,7 @@ void qpci_io_writel(QPCIDevice *dev, void *data, uint32_t value); > > void *qpci_iomap(QPCIDevice *dev, int barno, uint64_t *sizeptr); > void qpci_iounmap(QPCIDevice *dev, void *data); > +void *qpci_legacy_iomap(QPCIDevice *dev, uint16_t addr); > > void qpci_plug_device_test(const char *driver, const char *id, > uint8_t slot, const char *opts);