From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: BALATON Zoltan <balaton@eik.bme.hu>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Cc: "Hervé Poussineau" <hpoussin@reactos.org>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Nicholas Piggin" <npiggin@gmail.com>
Subject: Re: [PATCH v3 11/14] hw/pci-host/raven: Simpify discontiguous IO access
Date: Thu, 18 Sep 2025 21:49:40 +0100 [thread overview]
Message-ID: <c20c8e3c-dd4f-4331-a2aa-0faa01eb2b6c@ilande.co.uk> (raw)
In-Reply-To: <1ce9e69c55653d66dd2ead1a19ee779937847caa.1758219840.git.balaton@eik.bme.hu>
On 18/09/2025 19:50, BALATON Zoltan wrote:
> PREP allows remapping of the 64k ISA IO addresses from the normal
> contiguous IO space into a discontiguous 8MB region and can switch
> between the two modes. We can implement this in a simpler way than is
> done currently using an io region that forwards access to the
> contiguous pci_io region and enabling/disabling the discontiguous
> region as needed.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/pci-host/raven.c | 88 ++++++++++++---------------------------------
> 1 file changed, 22 insertions(+), 66 deletions(-)
>
> diff --git a/hw/pci-host/raven.c b/hw/pci-host/raven.c
> index bb0be40eb4..bf4f4b7f71 100644
> --- a/hw/pci-host/raven.c
> +++ b/hw/pci-host/raven.c
> @@ -42,17 +42,14 @@ struct PREPPCIState {
> PCIHostState parent_obj;
>
> qemu_irq irq;
> - AddressSpace pci_io_as;
> MemoryRegion pci_io;
> - MemoryRegion pci_io_non_contiguous;
> + MemoryRegion pci_discontiguous_io;
> MemoryRegion pci_memory;
> MemoryRegion pci_intack;
> MemoryRegion bm;
> MemoryRegion bm_ram_alias;
> MemoryRegion bm_pci_memory_alias;
> AddressSpace bm_as;
> -
> - int contiguous_map;
> };
>
> #define PCI_IO_BASE_ADDR 0x80000000 /* Physical address on main bus */
> @@ -103,63 +100,28 @@ static const MemoryRegionOps raven_intack_ops = {
> },
> };
>
> -static inline hwaddr raven_io_address(PREPPCIState *s,
> - hwaddr addr)
> +/* Convert 8 MB non-contiguous address to 64k ISA IO address */
> +static inline hwaddr raven_io_addr(hwaddr addr)
> {
> - if (s->contiguous_map == 0) {
> - /* 64 KB contiguous space for IOs */
> - addr &= 0xFFFF;
> - } else {
> - /* 8 MB non-contiguous space for IOs */
> - addr = (addr & 0x1F) | ((addr & 0x007FFF000) >> 7);
> - }
> -
> - /* FIXME: handle endianness switch */
> -
> - return addr;
> + return ((addr & 0x007FFF000) >> 7) | (addr & 0x1F);
> }
>
> -static uint64_t raven_io_read(void *opaque, hwaddr addr,
> - unsigned int size)
> +static uint64_t raven_io_read(void *opaque, hwaddr addr, unsigned int size)
> {
> - PREPPCIState *s = opaque;
> - uint8_t buf[4];
> -
> - addr = raven_io_address(s, addr);
> - address_space_read(&s->pci_io_as, addr + PCI_IO_BASE_ADDR,
> - MEMTXATTRS_UNSPECIFIED, buf, size);
> -
> - if (size == 1) {
> - return buf[0];
> - } else if (size == 2) {
> - return lduw_le_p(buf);
> - } else if (size == 4) {
> - return ldl_le_p(buf);
> - } else {
> - g_assert_not_reached();
> - }
> + uint64_t val = 0xffffffffULL;
> +
> + memory_region_dispatch_read(opaque, raven_io_addr(addr), &val,
> + size_memop(size) | MO_LE,
> + MEMTXATTRS_UNSPECIFIED);
> + return val;
> }
I'm guessing the dispatch target is guaranteed not to be a RAM-backed memory region?
> -static void raven_io_write(void *opaque, hwaddr addr,
> - uint64_t val, unsigned int size)
> +static void raven_io_write(void *opaque, hwaddr addr, uint64_t val,
> + unsigned int size)
> {
> - PREPPCIState *s = opaque;
> - uint8_t buf[4];
> -
> - addr = raven_io_address(s, addr);
> -
> - if (size == 1) {
> - buf[0] = val;
> - } else if (size == 2) {
> - stw_le_p(buf, val);
> - } else if (size == 4) {
> - stl_le_p(buf, val);
> - } else {
> - g_assert_not_reached();
> - }
> -
> - address_space_write(&s->pci_io_as, addr + PCI_IO_BASE_ADDR,
> - MEMTXATTRS_UNSPECIFIED, buf, size);
> + memory_region_dispatch_write(opaque, raven_io_addr(addr), val,
> + size_memop(size) | MO_LE,
> + MEMTXATTRS_UNSPECIFIED);
> }
>
> static const MemoryRegionOps raven_io_ops = {
> @@ -208,7 +170,7 @@ static void raven_change_gpio(void *opaque, int n, int level)
> {
> PREPPCIState *s = opaque;
>
> - s->contiguous_map = level;
> + memory_region_set_enabled(&s->pci_discontiguous_io, !!level);
> }
>
> static void raven_pcihost_realizefn(DeviceState *d, Error **errp)
> @@ -254,23 +216,17 @@ static void raven_pcihost_initfn(Object *obj)
> MemoryRegion *address_space_mem = get_system_memory();
>
> memory_region_init(&s->pci_io, obj, "pci-io", 0x3f800000);
> - memory_region_init_io(&s->pci_io_non_contiguous, obj, &raven_io_ops, s,
> - "pci-io-non-contiguous", 0x00800000);
> + memory_region_init_io(&s->pci_discontiguous_io, obj,
> + &raven_io_ops, &s->pci_io,
> + "pci-discontiguous-io", 8 * MiB);
Again I think passing the device as the opaque is easier to understand.
> memory_region_init(&s->pci_memory, obj, "pci-memory", 0x3f000000);
> - address_space_init(&s->pci_io_as, &s->pci_io, "raven-io");
> -
> - /*
> - * Raven's raven_io_ops use the address-space API to access pci-conf-idx
> - * (which is also owned by the raven device). As such, mark the
> - * pci_io_non_contiguous as re-entrancy safe.
> - */
> - s->pci_io_non_contiguous.disable_reentrancy_guard = true;
>
> /* CPU address space */
> memory_region_add_subregion(address_space_mem, PCI_IO_BASE_ADDR,
> &s->pci_io);
> memory_region_add_subregion_overlap(address_space_mem, PCI_IO_BASE_ADDR,
> - &s->pci_io_non_contiguous, 1);
> + &s->pci_discontiguous_io, 1);
> + memory_region_set_enabled(&s->pci_discontiguous_io, false);
> memory_region_add_subregion(address_space_mem, 0xc0000000, &s->pci_memory);
>
> /* Bus master address space */
Out of curiosity do you have an image or firmware that tests this?
ATB,
Mark.
next prev parent reply other threads:[~2025-09-18 20:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 18:50 [PATCH v3 00/14] hw/pci-host/raven clean ups BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 01/14] hw/pci-host/raven: Simplify PCI facing part BALATON Zoltan
2025-09-18 19:15 ` Mark Cave-Ayland
2025-09-18 20:21 ` BALATON Zoltan
2025-10-18 2:41 ` Harsh Prateek Bora
2025-10-18 11:24 ` BALATON Zoltan
2025-10-19 21:40 ` Mark Cave-Ayland
2025-10-19 23:26 ` BALATON Zoltan
2025-10-21 4:02 ` Harsh Prateek Bora
2025-09-18 18:50 ` [PATCH v3 02/14] hw/pci-host/raven: Simplify host bridge type declaration BALATON Zoltan
2025-09-18 19:16 ` Mark Cave-Ayland
2025-09-18 18:50 ` [PATCH v3 03/14] hw/pci-host/raven: Use DEFINE_TYPES macro BALATON Zoltan
2025-09-18 19:16 ` Mark Cave-Ayland
2025-09-18 18:50 ` [PATCH v3 04/14] hw/pci-host/raven: Simplify PCI bus creation BALATON Zoltan
2025-09-18 19:22 ` Mark Cave-Ayland
2025-09-18 18:50 ` [PATCH v3 05/14] hw/pci-host/raven: Simplify PCI interrupt routing BALATON Zoltan
2025-09-18 19:35 ` Mark Cave-Ayland
2025-09-18 20:52 ` BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 06/14] hw/pci-host/raven: Simplify direct config access address decoding BALATON Zoltan
2025-09-18 19:43 ` Mark Cave-Ayland
2025-10-20 8:37 ` Philippe Mathieu-Daudé
2025-09-18 18:50 ` [PATCH v3 07/14] hw/pci-host/raven: Rename direct config access ops BALATON Zoltan
2025-09-18 19:44 ` Mark Cave-Ayland
2025-10-20 8:38 ` Philippe Mathieu-Daudé
2025-09-18 18:50 ` [PATCH v3 08/14] hw/pci-host/raven: Use correct parameter in direct " BALATON Zoltan
2025-09-18 19:52 ` Mark Cave-Ayland
2025-09-18 21:01 ` BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 09/14] hw/pci-host/raven: Do not use parent object for mmcfg region BALATON Zoltan
2025-09-18 20:34 ` Mark Cave-Ayland
2025-09-18 21:04 ` BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 10/14] hw/pci-host/raven: Fix PCI config direct access region BALATON Zoltan
2025-09-18 20:35 ` Mark Cave-Ayland
2025-09-18 18:50 ` [PATCH v3 11/14] hw/pci-host/raven: Simpify discontiguous IO access BALATON Zoltan
2025-09-18 20:49 ` Mark Cave-Ayland [this message]
2025-09-18 21:11 ` BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 12/14] hw/pci-host/raven: Move bus master address space creation to one place BALATON Zoltan
2025-09-18 20:54 ` Mark Cave-Ayland
2025-09-18 21:13 ` BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 13/14] hw/pci-host/raven: Do not map regions in init method BALATON Zoltan
2025-09-18 21:02 ` Mark Cave-Ayland
2025-09-18 21:22 ` BALATON Zoltan
2025-09-18 18:50 ` [PATCH v3 14/14] hw/ppc/prep: Fix non-contiguous IO control bit BALATON Zoltan
2025-09-18 21:09 ` Mark Cave-Ayland
2025-09-18 21:33 ` BALATON Zoltan
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=c20c8e3c-dd4f-4331-a2aa-0faa01eb2b6c@ilande.co.uk \
--to=mark.cave-ayland@ilande.co.uk \
--cc=atar4qemu@gmail.com \
--cc=balaton@eik.bme.hu \
--cc=hpoussin@reactos.org \
--cc=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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).