From: Bernhard Beschow <shentey@gmail.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Eduardo Habkost <eduardo@habkost.net>
Subject: Re: [PATCH 15/15] hw/i386/pc_piix: Move i440fx' realize near its qdev_new()
Date: Mon, 12 Jun 2023 17:49:10 +0000 [thread overview]
Message-ID: <4F200210-F39C-49CD-B7FD-AF9F556C8493@gmail.com> (raw)
In-Reply-To: <20230612172119.5b9e6d7e@imammedo.users.ipa.redhat.com>
Am 12. Juni 2023 15:21:19 UTC schrieb Igor Mammedov <imammedo@redhat.com>:
>On Mon, 12 Jun 2023 16:51:55 +0200
>Igor Mammedov <imammedo@redhat.com> wrote:
>
>> On Sun, 11 Jun 2023 12:34:12 +0200
>> Bernhard Beschow <shentey@gmail.com> wrote:
>>
>> > I440FX realization is currently mixed with PIIX3 creation. Furthermore, it is
>> > common practice to only set properties between a device's qdev_new() and
>> > qdev_realize(). Clean up to resolve both issues.
>> >
>> > Since I440FX spawns a PCI bus let's also move the pci_bus initialization there.
>> >
>> > Note that when running `qemu-system-x86_64 -M pc -S` before and after this
>> > patch, `info mtree` in the QEMU console doesn't show any differences except that
>> > the ordering is different.
>> >
>> > Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> > ---
>> > hw/i386/pc_piix.c | 57 ++++++++++++++++++++++++-----------------------
>> > 1 file changed, 29 insertions(+), 28 deletions(-)
>> >
>> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> > index 22173b122b..23b9725c94 100644
>> > --- a/hw/i386/pc_piix.c
>> > +++ b/hw/i386/pc_piix.c
>> > @@ -126,7 +126,6 @@ static void pc_init1(MachineState *machine,
>> > MemoryRegion *rom_memory;
>> > ram_addr_t lowmem;
>> > uint64_t hole64_size;
>> > - Object *i440fx_host;
>> >
>> > /*
>> > * Calculate ram split, for memory below and above 4G. It's a bit
>> > @@ -198,17 +197,43 @@ static void pc_init1(MachineState *machine,
>> > }
>> >
>> > if (pcmc->pci_enabled) {
>> > + Object *phb;
>> > +
>> > pci_memory = g_new(MemoryRegion, 1);
>> > memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
>> > rom_memory = pci_memory;
>> > - i440fx_host = OBJECT(qdev_new(host_type));
>> > - hole64_size = object_property_get_uint(i440fx_host,
>> > +
>> > + phb = OBJECT(qdev_new(host_type));
>> > + object_property_add_child(OBJECT(machine), "i440fx", phb);
>> > + object_property_set_link(phb, PCI_HOST_PROP_RAM_MEM,
>> > + OBJECT(ram_memory), &error_fatal);
>> > + object_property_set_link(phb, PCI_HOST_PROP_PCI_MEM,
>> > + OBJECT(pci_memory), &error_fatal);
>> > + object_property_set_link(phb, PCI_HOST_PROP_SYSTEM_MEM,
>> > + OBJECT(system_memory), &error_fatal);
>> > + object_property_set_link(phb, PCI_HOST_PROP_IO_MEM,
>> > + OBJECT(system_io), &error_fatal);
>> > + object_property_set_uint(phb, PCI_HOST_BELOW_4G_MEM_SIZE,
>> > + x86ms->below_4g_mem_size, &error_fatal);
>> > + object_property_set_uint(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
>> > + x86ms->above_4g_mem_size, &error_fatal);
>> > + object_property_set_str(phb, I440FX_HOST_PROP_PCI_TYPE, pci_type,
>> > + &error_fatal);
>> > + sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
>> > +
>> > + pci_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
>> > + pci_bus_map_irqs(pci_bus,
>> > + xen_enabled() ? xen_pci_slot_get_pirq
>> > + : pc_pci_slot_get_pirq);
>> > + pcms->bus = pci_bus;
>> > +
>> > + hole64_size = object_property_get_uint(phb,
>> > PCI_HOST_PROP_PCI_HOLE64_SIZE,
>> > &error_abort);
>>
>> before patch memory region links were set after the original
>> regions were initialized by pc_memory_init(), but after this
>> patch you 1st set links and only later pc_memory_init().
>> I doesn't look to me as a safe thing to do.
>
>or maybe it doesn't matter, but still I have hard time
>convincing myself that it is so.
AFAICS both pc_memory_init() and i440fx_pcihost_realize() rely on memory_region_init*() having been called on these pointers already. All they seem to do is adding their sub regions. The order in which this happens seems to be irrelevant, otherwise we'd see changes in the QOM console calls I guess.
>
>>
>> > } else {
>>
>>
>> > pci_memory = NULL;
>> > rom_memory = system_memory;
>> > - i440fx_host = NULL;
>> > + pci_bus = NULL;
>> > hole64_size = 0;
>>
>> is it possible to turn these into initializers, and get rid of
>> 'else' branch?
Sure, this is possible. I'd add another patch before this one.
Best regards,
Bernhard
>>
>> > }
>> >
>> > @@ -243,29 +268,6 @@ static void pc_init1(MachineState *machine,
>> > PIIX3State *piix3;
>> > PCIDevice *pci_dev;
>> >
>> > - object_property_add_child(OBJECT(machine), "i440fx", i440fx_host);
>> > - object_property_set_link(i440fx_host, PCI_HOST_PROP_RAM_MEM,
>> > - OBJECT(ram_memory), &error_fatal);
>> > - object_property_set_link(i440fx_host, PCI_HOST_PROP_PCI_MEM,
>> > - OBJECT(pci_memory), &error_fatal);
>> > - object_property_set_link(i440fx_host, PCI_HOST_PROP_SYSTEM_MEM,
>> > - OBJECT(system_memory), &error_fatal);
>> > - object_property_set_link(i440fx_host, PCI_HOST_PROP_IO_MEM,
>> > - OBJECT(system_io), &error_fatal);
>> > - object_property_set_uint(i440fx_host, PCI_HOST_BELOW_4G_MEM_SIZE,
>> > - x86ms->below_4g_mem_size, &error_fatal);
>> > - object_property_set_uint(i440fx_host, PCI_HOST_ABOVE_4G_MEM_SIZE,
>> > - x86ms->above_4g_mem_size, &error_fatal);
>> > - object_property_set_str(i440fx_host, I440FX_HOST_PROP_PCI_TYPE,
>> > - pci_type, &error_fatal);
>> > - sysbus_realize_and_unref(SYS_BUS_DEVICE(i440fx_host), &error_fatal);
>> > -
>> > - pci_bus = PCI_BUS(qdev_get_child_bus(DEVICE(i440fx_host), "pci.0"));
>> > - pci_bus_map_irqs(pci_bus,
>> > - xen_enabled() ? xen_pci_slot_get_pirq
>> > - : pc_pci_slot_get_pirq);
>> > - pcms->bus = pci_bus;
>> > -
>> > pci_dev = pci_create_simple_multifunction(pci_bus, -1, true,
>> > TYPE_PIIX3_DEVICE);
>> >
>> > @@ -290,7 +292,6 @@ static void pc_init1(MachineState *machine,
>> > rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(pci_dev),
>> > "rtc"));
>> > } else {
>> > - pci_bus = NULL;
>> > isa_bus = isa_bus_new(NULL, system_memory, system_io,
>> > &error_abort);
>> >
>>
>
next prev parent reply other threads:[~2023-06-12 19:25 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-11 10:33 [PATCH 00/15] Q35 and I440FX host bridge QOM cleanup Bernhard Beschow
2023-06-11 10:33 ` [PATCH 01/15] hw/i386/pc_q35: Resolve redundant q35_host variable Bernhard Beschow
2023-06-11 10:33 ` [PATCH 02/15] hw/pci-host/q35: Fix double, contradicting .endianness assignment Bernhard Beschow
2023-06-12 13:01 ` Igor Mammedov
2023-06-13 7:46 ` Bernhard Beschow
2023-06-13 8:51 ` Michael S. Tsirkin
2023-06-13 11:07 ` BALATON Zoltan
2023-06-13 13:05 ` Igor Mammedov
2023-06-13 13:40 ` Philippe Mathieu-Daudé
2023-06-13 15:01 ` Michael S. Tsirkin
2023-06-13 15:28 ` Bernhard Beschow
2023-06-11 10:34 ` [PATCH 03/15] hw/pci-host/q35: Initialize PCMachineState::bus in board code Bernhard Beschow
2023-06-12 10:28 ` Philippe Mathieu-Daudé
2023-06-12 13:42 ` Igor Mammedov
2023-06-11 10:34 ` [PATCH 04/15] hw/pci/pci_host: Introduce PCI_HOST_BYPASS_IOMMU macro Bernhard Beschow
2023-06-12 13:45 ` Igor Mammedov
2023-06-11 10:34 ` [PATCH 05/15] hw/pci-host/q35: Initialize PCI_HOST_BYPASS_IOMMU property from board code Bernhard Beschow
2023-06-12 10:27 ` Philippe Mathieu-Daudé
2023-06-12 13:51 ` Igor Mammedov
2023-06-11 10:34 ` [PATCH 06/15] hw/pci-host/q35: Make some property name macros reusable by i440fx Bernhard Beschow
2023-06-11 10:34 ` [PATCH 07/15] hw/pci-host/i440fx: Replace magic values by existing constants Bernhard Beschow
2023-06-12 10:25 ` Philippe Mathieu-Daudé
2023-06-12 13:55 ` Igor Mammedov
2023-06-11 10:34 ` [PATCH 08/15] hw/pci-host/i440fx: Have common names for some local variables Bernhard Beschow
2023-06-12 10:25 ` Philippe Mathieu-Daudé
2023-06-11 10:34 ` [PATCH 09/15] hw/pci-host/i440fx: Move i440fx_realize() into PCII440FXState section Bernhard Beschow
2023-06-12 10:24 ` Philippe Mathieu-Daudé
2023-06-11 10:34 ` [PATCH 10/15] hw/pci-host/i440fx: Make MemoryRegion pointers accessible as properties Bernhard Beschow
2023-06-12 10:19 ` Philippe Mathieu-Daudé
2023-06-11 10:34 ` [PATCH 11/15] hw/pci-host/i440fx: Add PCI_HOST_PROP_IO_MEM property Bernhard Beschow
2023-06-12 10:31 ` Philippe Mathieu-Daudé
2023-06-12 17:54 ` Bernhard Beschow
2023-06-11 10:34 ` [PATCH 12/15] hw/pci-host/i440fx: Add PCI_HOST_{ABOVE, BELOW}_4G_MEM_SIZE properties Bernhard Beschow
2023-06-11 10:34 ` [PATCH 13/15] hw/pci-host/i440fx: Add I440FX_HOST_PROP_PCI_TYPE property Bernhard Beschow
2023-06-11 10:34 ` [PATCH 14/15] hw/pci-host/i440fx: Resolve i440fx_init() Bernhard Beschow
2023-06-11 10:34 ` [PATCH 15/15] hw/i386/pc_piix: Move i440fx' realize near its qdev_new() Bernhard Beschow
2023-06-12 9:40 ` Philippe Mathieu-Daudé
2023-06-12 14:51 ` Igor Mammedov
2023-06-12 15:21 ` Igor Mammedov
2023-06-12 17:49 ` Bernhard Beschow [this message]
2023-06-13 9:52 ` Igor Mammedov
2023-06-26 6:50 ` 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=4F200210-F39C-49CD-B7FD-AF9F556C8493@gmail.com \
--to=shentey@gmail.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).