qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O


From: Andreas Färber
Subject: Re: [Qemu-ppc] [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O
Date: Wed, 30 Jan 2013 21:19:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 30.01.2013 18:29, schrieb Anthony Liguori:
> Andreas Färber <address@hidden> writes:
> 
>> Am 30.01.2013 17:33, schrieb Anthony Liguori:
>>> Gerd Hoffmann <address@hidden> writes:
>>>
>>>>> hw/qxl.c:    portio_list_add(qxl_vga_port_list,
>>>>> pci_address_space_io(dev), 0x3b0);
>>>>> hw/vga.c:        portio_list_add(vga_port_list, address_space_io, 0x3b0);
>>>>
>>>> That reminds me I should solve this in a more elegant way.
>>>>
>>>> qxl takes over the vga io ports.  The reason it does this is because qxl
>>>> switches into vga mode in case the vga ports are accessed while not in
>>>> vga mode.  After doing the check (and possibly switching mode) the vga
>>>> handler is called to actually handle it.
>>>
>>> The best way to handle this would be to remodel how we do VGA.
>>>
>>> Make VGACommonState a proper QOM object and use it as the base class for
>>> QXL, CirrusVGA, QEMUVGA (std-vga), and VMwareVGA.
>>
>> That would require polymorphism since we already need to derive from
>> PCIDevice or ISADevice respectively for interfacing with the bus...
> 
> Nope.  You can use composition:
> 
> QXLDevice is-a VGACommonState
> 
> QXLPCI is-a PCIDevice
>        has-a QXLDevice
> 
>> Modern object-oriented languages have tried to avoid multi-inheritence
>> due to arising complications, I thought. Wouldn't object if someone
>> wanted to do the dirty implementation work though. ;)
> 
> There is no need for MI.
> 
>> Another such example is EHCI, with PCIDevice and SysBusDevice frontends,
>> sharing an EHCIState struct and having helper functions operating on
>> that core state only. Quite a few device share such a pattern today
>> actually (serial, m48t59, ...).
> 
> Yes, this is all about chipset modelling.  Chipsets should derive from
> device and then be embedded in the appropriate bus device.
> 
> For instance.
> 
> SerialState is-a DeviceState
> 
> ISASerialState is-a ISADevice, has-a SerialState
> MMIOSerialState is-a SysbusDevice, has-a SerialState

Okay, but I don't like that both are transitively DeviceState then.
It's much too easy to add / hot-add the wrong device then, especially
when dropping no_user.

Andreas

> This is what we're doing in practice, we just aren't modeling the
> chipsets and we're open coding the relationships (often in subtley
> different ways).
> 
> Regards,
> 
> Anthony Liguori


-- 
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]