From patchwork Tue Feb 18 20:15:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 3674361 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 2373BBF13A for ; Tue, 18 Feb 2014 20:15:45 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3E05120165 for ; Tue, 18 Feb 2014 20:15:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5ED2020114 for ; Tue, 18 Feb 2014 20:15:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751142AbaBRUPm (ORCPT ); Tue, 18 Feb 2014 15:15:42 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:54038 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbaBRUPl (ORCPT ); Tue, 18 Feb 2014 15:15:41 -0500 Received: from wuerfel.localnet (HSI-KBW-5-56-226-176.hsi17.kabel-badenwuerttemberg.de [5.56.226.176]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0Mg2HB-1WciyU0x1h-00NPEQ; Tue, 18 Feb 2014 21:15:15 +0100 From: Arnd Bergmann To: Will Deacon Cc: Jason Gunthorpe , "linux-arm-kernel@lists.infradead.org" , "linux-pci@vger.kernel.org" , "bhelgaas@google.com" Subject: Re: [PATCH v3 3/3] PCI: ARM: add support for generic PCI host controller Date: Tue, 18 Feb 2014 21:15:12 +0100 Message-ID: <3220206.h6hgmMzWTX@wuerfel> User-Agent: KMail/4.11.3 (Linux/3.11.0-15-generic; KDE/4.11.3; x86_64; ; ) In-Reply-To: <20140218184420.GD2010@mudshark.cambridge.arm.com> References: <1392726043-31088-1-git-send-email-will.deacon@arm.com> <20140218182142.GF29304@obsidianresearch.com> <20140218184420.GD2010@mudshark.cambridge.arm.com> MIME-Version: 1.0 X-Provags-ID: V02:K0:0qZcRaHylWkHG2sIzJ6LbMlKGmxzq0EbYmYSoaEHn2a dKWSTjzaEiNh9FwXIXFqpX1tp5EEieI2zClylI/ZuGVnoypabN DmlibqmonTm07qAbaCrkYmoY1Tyy39y2W8r+xeKqoc0nglmRwV y/Llypq3Xr5gFX8MquE5g3IH24axBgv3+DmlKbRQHqoMi5UDTt yqFiuU4bfxg75+jkmiyQJsL8U/PFaakD8BiIXhQhOrbFFJnYii cAXoLKlhuQww82OEyOqKnVSF5MRJo8KomKW6o6nVShBwgpVrKU kGpPtfrrybXLj+0kPn2R/0fu6ELswdw8HVOuy7nj43L7XoCOnI K1q0NFymS72LnU3poCxk= Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tuesday 18 February 2014 18:44:20 Will Deacon wrote: > On Tue, Feb 18, 2014 at 06:21:42PM +0000, Jason Gunthorpe wrote: > > On Tue, Feb 18, 2014 at 12:20:43PM +0000, Will Deacon wrote: > > > + > > > + // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2) > > > + ranges = <0x1000000 0x0 0x00000000 0x0 0x00000000 0x0 0x00010000>, > > ^^^^^^^^^^^^^^ > > > > This probably shouldn't be 0 in the example, nor in your kvm tool > > output. For example purposes any value will do. > > Hmm, so kvmtool actually provides a PC ioport at 0x0, which is handy since > there's an 8250 down there. That means we have: > > 0x0 - 0x6200 : Weird PC stuff > 0x6200 - 0x10000 : PCI IO space > > Should I just change everything to be offset by 0x6200? Some more comments about this: * After I looked at the kvmtool code some more, I think it would be nice to actually move the I/O space window to a nonzero location, e.g. between the PCI space and the AXI space. It's really confusing the way it is, and easy to introduce bugs if you have any code that accidentally relies on the numbers matching up. For all I can tell, kvmtool should just work fine with any definition of ARM_IOPORT_AREA, as long as you apply the trivial patch below. * pci_get_io_space_block() is a very confusing name for a function that allocates a memory space block in kvmtool. It seems that KVM_IOPORT_AREA is a misnomer for the same reason. Note that PowerPC sets KVM_IOPORT_AREA to zero, but has the I/O space window at SPAPR_PCI_IO_WIN_ADDR, which is non-zero. * It's interesting that you also support I/O space access to the PCI config space through PC-Style ports 0cf8-0cff. Not sure if that helps at all, but it is another standard way to probe the bus that could easily be implemented as an alternative to CAM and ECAM, in a generic PCI host driver. Arnd --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/tools/kvm/arm/kvm-cpu.c b/tools/kvm/arm/kvm-cpu.c index b017994..caf9a57 100644 --- a/tools/kvm/arm/kvm-cpu.c +++ b/tools/kvm/arm/kvm-cpu.c @@ -105,7 +105,7 @@ bool kvm_cpu__emulate_mmio(struct kvm *kvm, u64 phys_addr, u8 *data, u32 len, return kvm__emulate_mmio(kvm, phys_addr, data, len, is_write); } else if (arm_addr_in_ioport_region(phys_addr)) { int direction = is_write ? KVM_EXIT_IO_OUT : KVM_EXIT_IO_IN; - u16 port = phys_addr & USHRT_MAX; + u16 port = (phys_addr - ARM_IOPORT_AREA) & USHRT_MAX; return kvm__emulate_io(kvm, port, data, direction, len, 1); } else if (arm_addr_in_pci_region(phys_addr)) { return kvm__emulate_mmio(kvm, phys_addr, data, len, is_write);