qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	"qemu-ppc@nongnu.org List" <qemu-ppc@nongnu.org>,
	Avi Kivity <avi@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH 13/14] PPC: e500: Map PIO space into core memory region
Date: Mon, 8 Oct 2012 16:30:04 -0500	[thread overview]
Message-ID: <1349731804.3721.11@snotra> (raw)
In-Reply-To: <11F10FDD-2CA3-4456-A77D-E45C249D8904@suse.de> (from agraf@suse.de on Mon Oct  8 16:08:31 2012)

On 10/08/2012 04:08:31 PM, Alexander Graf wrote:
> 
> On 08.10.2012, at 23:05, Scott Wood wrote:
> 
> > 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  
> bridge is
> >> >> accessible via MMIO. Do this mapping explicitly by mapping the  
> PIO space
> >> >> of our PCI bus into a memory region that lives in memory space.
> >> >> Signed-off-by: Alexander Graf <agraf@suse.de>
> >> >> ---
> >> >> 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 +  
> 0x8000ULL)
> >> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
> >> >> #define MPC8544_PCI_IO             0xE1000000ULL
> >> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
> >> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 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  
> (or rather, a board-related default of something that is supposed to  
> 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  
> the I/O instructions, and some (buggy?) PCI devices might have  
> trouble with larger I/O addresses, but I didn't think it was actually  
> illegal.  Some mpc85xx boards have default configs with larger I/O  
> windows (though probably not for any good reason).
> 
> What sense would it make to model an ioport range that exceeds what  
> x86 can do?

Well, as I said there's probably not a good reason for actually doing  
it, but if you want to more faithfully emulate the hardware...

That said, when I first complained I misread the constant and thought  
you were hardcoding 1M rather than 64K.

> >> > Any chance of similarly constraining PCI MMIO to its proper  
> window?
> >> We can't distinguish between inbound and outbound right now. If we  
> only need to restrict CPU -> PCI access, then yes.
> >
> > Better than nothing. :-)
> 
> If you can point me to the part of the spec that specifies how that  
> window should look like, I can cook up a patch. Or you can do it of  
> course ;).

Outbound windows are configured by PO*AR/PEXO*AR, and inbound by  
PI*AR/PEXI*AR (plus BAR0).  It's not a high priority, just curious what  
would be involved.

-Scott

  reply	other threads:[~2012-10-08 21:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08 12:23 [Qemu-devel] [PATCH 00/14] Remove old_portio users for memory region PIO mapping Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 01/14] ac97: convert PIO to new memory api read/write Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 02/14] virtio-pci: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 03/14] es1370: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 04/14] i8254: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 05/14] m48t59: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 06/14] mc146818rtc: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 07/14] pc port92: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 08/14] pckbd: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 09/14] rtl8139: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 10/14] serial: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 11/14] vmport: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 12/14] xen_platform: " Alexander Graf
2012-10-08 12:23 ` [Qemu-devel] [PATCH 13/14] PPC: e500: Map PIO space into core memory region Alexander Graf
2012-10-08 20:20   ` Scott Wood
2012-10-08 20:48     ` Alexander Graf
2012-10-08 21:05       ` Scott Wood
2012-10-08 21:08         ` Alexander Graf
2012-10-08 21:30           ` Scott Wood [this message]
2012-10-08 12:23 ` [Qemu-devel] [PATCH 14/14] PPC: pseries: Remove hack for PIO window Alexander Graf
2012-10-08 16:18 ` [Qemu-devel] [PATCH 00/14] Remove old_portio users for memory region PIO mapping Andreas Färber
2012-10-08 16:32   ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1349731804.3721.11@snotra \
    --to=scottwood@freescale.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).