From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLKuE-0005B4-Jk for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:30:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLKuD-0006Wm-5N for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:30:30 -0400 Date: Mon, 8 Oct 2012 16:30:04 -0500 From: Scott Wood In-Reply-To: <11F10FDD-2CA3-4456-A77D-E45C249D8904@suse.de> (from agraf@suse.de on Mon Oct 8 16:08:31 2012) Message-ID: <1349731804.3721.11@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 04:08:31 PM, Alexander Graf wrote: >=20 > On 08.10.2012, at 23:05, Scott Wood wrote: >=20 > > On 10/08/2012 03:48:42 PM, Alexander Graf wrote: > >> On 08.10.2012, at 22:20, Scott Wood wrote: > >> > 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 =20 > PIO 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 - =20 > 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. > >> 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 =20 > the I/O instructions, and some (buggy?) PCI devices might have =20 > trouble with larger I/O addresses, but I didn't think it was actually =20 > illegal. Some mpc85xx boards have default configs with larger I/O =20 > windows (though probably not for any good reason). >=20 > What sense would it make to model an ioport range that exceeds what =20 > x86 can do? Well, as I said there's probably not a good reason for actually doing =20 it, but if you want to more faithfully emulate the hardware... That said, when I first complained I misread the constant and thought =20 you were hardcoding 1M rather than 64K. > >> > Any chance of similarly constraining PCI MMIO to its proper =20 > window? > >> 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. :-) >=20 > If you can point me to the part of the spec that specifies how that =20 > window should look like, I can cook up a patch. Or you can do it of =20 > course ;). Outbound windows are configured by PO*AR/PEXO*AR, and inbound by =20 PI*AR/PEXI*AR (plus BAR0). It's not a high priority, just curious what =20 would be involved. -Scott=