From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLKW5-0005mK-FF for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:05:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLKW4-0005tw-EV for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:05:33 -0400 Date: Mon, 8 Oct 2012 16:05:18 -0500 From: Scott Wood In-Reply-To: <8FB35BE8-7239-4317-8CB3-420E5D4E2D68@suse.de> (from agraf@suse.de on Mon Oct 8 15:48:42 2012) Message-ID: <1349730318.3721.9@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 13/14] PPC: e500: Map PIO space into core memory region List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , xen-devel@lists.xensource.com, Stefano Stabellini , qemu-devel qemu-devel , "qemu-ppc@nongnu.org List" , Avi Kivity , David Gibson On 10/08/2012 03:48:42 PM, Alexander Graf wrote: >=20 > On 08.10.2012, at 22:20, Scott Wood wrote: >=20 > > On 10/08/2012 07:23:52 AM, Alexander Graf wrote: > >> On PPC, we don't have PIO. So usually PIO space behind a PCI =20 > bridge is > >> accessible via MMIO. Do this mapping explicitly by mapping the PIO =20 > space > >> of our PCI bus into a memory region that lives in memory space. > >> Signed-off-by: Alexander Graf > >> --- > >> hw/ppc/e500.c | 3 +-- > >> hw/ppce500_pci.c | 9 +++++++-- > >> 2 files changed, 8 insertions(+), 4 deletions(-) > >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c > >> index d23f9b2..857d4dc 100644 > >> --- a/hw/ppc/e500.c > >> +++ b/hw/ppc/e500.c > >> @@ -52,7 +52,6 @@ > >> #define MPC8544_PCI_REGS_BASE (MPC8544_CCSRBAR_BASE + =20 > 0x8000ULL) > >> #define MPC8544_PCI_REGS_SIZE 0x1000ULL > >> #define MPC8544_PCI_IO 0xE1000000ULL > >> -#define MPC8544_PCI_IOLEN 0x10000ULL > >> #define MPC8544_UTIL_BASE (MPC8544_CCSRBAR_BASE + =20 > 0xe0000ULL) > >> #define MPC8544_SPIN_BASE 0xEF000000ULL > >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params) > >> if (!pci_bus) > >> printf("couldn't create PCI controller!\n"); > >> - isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN); > >> + sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO); > >> if (pci_bus) { > >> /* Register network interfaces. */ > >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c > >> index 92b1dc0..27c6d7d 100644 > >> --- a/hw/ppce500_pci.c > >> +++ b/hw/ppce500_pci.c > >> @@ -31,6 +31,8 @@ > >> #define PCIE500_ALL_SIZE 0x1000 > >> #define PCIE500_REG_SIZE (PCIE500_ALL_SIZE - PCIE500_REG_BASE) > >> +#define PCIE500_PCI_IOLEN 0x10000ULL > > > > I don't think this belongs in ppce500_pci.c -- it's board config =20 > (or rather, a board-related default of something that is supposed to =20 > be software configurable), just like the base address. >=20 > Actually this one is fixed in PCI. There are only 64k PIO ports. Are you sure about that? Certainly that's the limit on x86 due to the =20 I/O instructions, and some (buggy?) PCI devices might have trouble with =20 larger I/O addresses, but I didn't think it was actually illegal. Some =20 mpc85xx boards have default configs with larger I/O windows (though =20 probably not for any good reason). > > Any chance of similarly constraining PCI MMIO to its proper window? >=20 > We can't distinguish between inbound and outbound right now. If we =20 > only need to restrict CPU -> PCI access, then yes. Better than nothing. :-) -Scott=