qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/2] pci_host: Turn into SysBus-derived QOM t


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2 1/2] pci_host: Turn into SysBus-derived QOM type
Date: Mon, 18 Jun 2012 23:44:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

Am 18.06.2012 20:28, schrieb Michael S. Tsirkin:
> On Sun, Jun 10, 2012 at 05:57:54PM +0200, Andreas Färber wrote:
>> From: Andreas Färber <address@hidden>
>>
>> Allows us to access PCIHostState QOM-style with PCI_HOST() macro.
>>
>> Update PReP Raven PCI to derive from this type.
>>
>> Signed-off-by: Anthony Liguori <address@hidden>
>> Signed-off-by: Wanpeng Li <address@hidden>
>> Signed-off-by: Andreas Färber <address@hidden>
>> Reviewed-by: Anthony Liguori <address@hidden>
> 
> Question: this is really a pci host *bridge*.
> We are calling this PCIHost internally for brevity
> but QOM hierarchy is user-visible, right?

That's a good question... I would say it's not user-visible today unless
we instantiate TYPE_PCI_HOST directly, in which case its value
"pci-host" would be visible through the "type" property that got
introduced on qom-next. My CPU modeling for instance is based on the
assumption that we can introduce intermediate types later as a
user-invisible implementation detail.

>> ---
>>  hw/pci_host.c |   11 +++++++++++
>>  hw/pci_host.h |    3 +++
>>  hw/prep_pci.c |    4 ++--
>>  3 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/pci_host.c b/hw/pci_host.c
>> index 8041778..347bfa6 100644
>> --- a/hw/pci_host.c
>> +++ b/hw/pci_host.c
>> @@ -165,4 +165,15 @@ const MemoryRegionOps pci_host_data_be_ops = {
>>      .endianness = DEVICE_BIG_ENDIAN,
>>  };
>>  
>> +static const TypeInfo pci_host_type_info = {
>> +    .name = TYPE_PCI_HOST,
>> +    .parent = TYPE_SYS_BUS_DEVICE,
>> +    .instance_size = sizeof(PCIHostState),
>> +};

It would in fact be better to set .abstract = true, I guess.

Anyway, I think for sPAPR I translated PHB to PCI_HOST_BRIDGE already,
so TYPE_PCI_HOST_BRIDGE "pci-host-bridge" and PCI_HOST_BRIDGE() would
fit in nicely with the otherwise clear and verbose QOM naming. But I'd
rather not rename PCIHostState everywhere... do you agree? Or would you
want to have it as PCIHostBridge or PCIHostBridgeState for consistency?

If we use TYPE_PCI_HOST_BRIDGE I should also add _BRIDGE for some of the
derived types, but we can't change the user-visible "-pcihost" type name
there for backwards compatibility.

Any further wishes? Should the second patch be split up in some way?

Andreas

>> +
>> +static void pci_host_register_types(void)
>> +{
>> +    type_register_static(&pci_host_type_info);
>> +}
>>  
>> +type_init(pci_host_register_types)
[snip]

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]