From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Bernhard Beschow <shentey@gmail.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sunil Muthuswamy <sunilmut@microsoft.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
qemu-trivial@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>,
Juan Quintela <quintela@redhat.com>,
Eduardo Habkost <eduardo@habkost.net>,
Thomas Huth <thuth@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
BALATON Zoltan <balaton@eik.bme.hu>, Ani Sinha <ani@anisinha.ca>,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH v4 1/9] hw/pci-host/i440fx: Inline sysbus_add_io()
Date: Tue, 7 Mar 2023 23:32:47 +0100 [thread overview]
Message-ID: <4ef9dedc-ce1c-b0f1-281f-e0c49b4e04d7@linaro.org> (raw)
In-Reply-To: <EA2E3787-179C-4A50-9305-969404D09702@gmail.com>
On 6/3/23 07:57, Bernhard Beschow wrote:
>
>
> Am 22. Februar 2023 18:05:51 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>>
>>
>> Am 22. Februar 2023 10:58:08 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>>> On 13/2/23 17:19, Bernhard Beschow wrote:
>>>> sysbus_add_io() just wraps memory_region_add_subregion() while also
>>>> obscuring where the memory is attached. So use
>>>> memory_region_add_subregion() directly and attach it to the existing
>>>> memory region s->bus->address_space_io which is set as an alias to
>>>> get_system_io() by the pc machine.
>>>>
>>>> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>>>> Reviewed-by: Thomas Huth <thuth@redhat.com>
>>>> ---
>>>> hw/pci-host/i440fx.c | 5 +++--
>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
>>>> index 262f82c303..9c6882d3fc 100644
>>>> --- a/hw/pci-host/i440fx.c
>>>> +++ b/hw/pci-host/i440fx.c
>>>> @@ -27,6 +27,7 @@
>>>> #include "qemu/range.h"
>>>> #include "hw/i386/pc.h"
>>>> #include "hw/pci/pci.h"
>>>> +#include "hw/pci/pci_bus.h"
>>>> #include "hw/pci/pci_host.h"
>>>> #include "hw/pci-host/i440fx.h"
>>>> #include "hw/qdev-properties.h"
>>>> @@ -217,10 +218,10 @@ static void i440fx_pcihost_realize(DeviceState *dev, Error **errp)
>>>> PCIHostState *s = PCI_HOST_BRIDGE(dev);
>>>> SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
>>>> - sysbus_add_io(sbd, 0xcf8, &s->conf_mem);
>>>> + memory_region_add_subregion(s->bus->address_space_io, 0xcf8, &s->conf_mem);
>>>
>>> To avoid accessing internal fields we should stick to the PCI API:
>>>
>>> memory_region_add_subregion(pci_address_space_io(PCI_DEVICE(dev)),
>>> 0xcf8, &s->conf_mem);
>>
>> dev is of type PCIHostState which derives from SysBusDevice, not PCIDevice. AFAICS there is no getter implemented on PCIBus.
You are right, there is no getter for PCIBus::address_space_io,
it is accessed directly:
MemoryRegion *pci_address_space_io(PCIDevice *dev)
{
return pci_get_bus(dev)->address_space_io;
}
If it is considered a property, probably no need for getter.
So:
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>
>>
>>>
>>>> sysbus_init_ioports(sbd, 0xcf8, 4);
>>>> - sysbus_add_io(sbd, 0xcfc, &s->data_mem);
>>>> + memory_region_add_subregion(s->bus->address_space_io, 0xcfc, &s->data_mem);
>>>> sysbus_init_ioports(sbd, 0xcfc, 4);
>>>
>>> Now all classes implementing PCI_HOST_BRIDGE register conf/data in I/O
>>> space, so this could be a pattern justifying reworking a bit the
>>> PCIHostBridgeClass or adding an helper in "hw/pci/pci_host.h" to do
>>> that generically.
(this comment is besides the scope of this patch)
>> What do you mean exactly? There are PCI hosts spawning two PCI buses and therefore have two such spaces.
I haven't checked but IIRC each PCI host exposing I/O registers
to access buses via ISA I/O open-code it. Even if it exposes
multiple buses, the same pattern is used (1 time per bus).
Anyway, no need to worry about that now...
next prev parent reply other threads:[~2023-03-07 22:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 16:19 [PATCH v4 0/9] PC cleanups Bernhard Beschow
2023-02-13 16:19 ` [PATCH v4 1/9] hw/pci-host/i440fx: Inline sysbus_add_io() Bernhard Beschow
2023-02-22 10:58 ` Philippe Mathieu-Daudé
2023-02-22 18:05 ` Bernhard Beschow
2023-03-06 6:57 ` Bernhard Beschow
2023-03-07 22:32 ` Philippe Mathieu-Daudé [this message]
2023-02-13 16:19 ` [PATCH v4 2/9] hw/pci-host/q35: " Bernhard Beschow
2023-02-13 16:19 ` [PATCH v4 3/9] hw/i386/pc_q35: Reuse machine parameter Bernhard Beschow
2023-02-22 11:03 ` Philippe Mathieu-Daudé
2023-02-22 17:52 ` Bernhard Beschow
2023-02-22 20:24 ` Michael S. Tsirkin
2023-02-13 16:19 ` [PATCH v4 4/9] hw/i386/pc_{q35, piix}: Reuse MachineClass::desc as SMB product name Bernhard Beschow
2023-02-13 16:20 ` [PATCH v4 5/9] hw/i386/pc_{q35, piix}: Minimize usage of get_system_memory() Bernhard Beschow
2023-02-22 11:05 ` Philippe Mathieu-Daudé
2023-02-13 16:20 ` [PATCH v4 6/9] hw/i386/pc: Initialize ram_memory variable directly Bernhard Beschow
2023-02-22 2:38 ` Xiaoyao Li
2023-02-22 8:21 ` Bernhard Beschow
2023-02-13 16:20 ` [PATCH v4 7/9] hw/pci-host/pam: Make init_pam() usage more readable Bernhard Beschow
2023-02-13 16:20 ` [PATCH v4 8/9] hw/i386/x86: Make TYPE_X86_MACHINE the owner of smram Bernhard Beschow
2023-02-13 16:20 ` [PATCH v4 9/9] target/i386/tcg/sysemu/tcg-cpu: Avoid own opinion about smram size Bernhard Beschow
2023-02-13 16:45 ` [PATCH v4 0/9] PC cleanups Bernhard Beschow
2023-03-05 7:45 ` Bernhard Beschow
2023-03-05 10:09 ` Michael S. Tsirkin
2023-03-07 22:34 ` Philippe Mathieu-Daudé
2023-05-10 18:26 ` Bernhard Beschow
2023-05-10 19:20 ` Michael S. Tsirkin
2023-05-10 21:19 ` Bernhard Beschow
2023-02-21 15:40 ` Bernhard Beschow
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=4ef9dedc-ce1c-b0f1-281f-e0c49b4e04d7@linaro.org \
--to=philmd@linaro.org \
--cc=ani@anisinha.ca \
--cc=balaton@eik.bme.hu \
--cc=dgilbert@redhat.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=shentey@gmail.com \
--cc=sunilmut@microsoft.com \
--cc=thuth@redhat.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).