Re: [Qemu-devel] q35 chipset support

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/18/2012 10:36 AM, Andreas Färber wrote:
> Am 18.06.2012 16:37, schrieb Michael S. Tsirkin:
>> On Mon, Jun 18, 2012 at 09:22:43AM -0500, Anthony Liguori wrote:
>>> On 06/18/2012 09:20 AM, Michael S. Tsirkin wrote:
>>>> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
>>>>> So we need to fix our topological representation of platform devices
>>>>> before we start adding more complex chipsets.  Otherwise, we're
>>>>> going to end up in a bad situation in the near future.
>>>>
>>>> OTOH more in-tree examples especially for x86 will keep us
>>>> honest: help make sure abstractions make sense,
>>>> and prevent people from special casing piix because
>>>> this is the prevalent platform for kvm ATM.
>>>
>>> Yes, more in-tree *correct* examples.  I'm very much in favor of merging q35.
>>
>> But is there a way to build a correct chipset right now?
>> Or is this blocked waiting for more infrastructure
>> to get merged?
>
> The qom-next PULL (with QBus type) is out and Anthony has reviewed my
> pci_host mini-series, those two would be good to have as groundwork.
> Anything else (e.g., an LPCBus if needed) could be done in the q35
> series IIUC.
>
> Having q35 modeled with in-place initialization should probably not be a
> hard requirement, relaxing the PCIBus availability issue.

All I think is required is that we have the right hiearchy of devices.  I don't 
mind if we're not doing two-stage initialization but we need to make sure the 
device hierarchy represents what the guest expects to see.

Regards,

Anthony Liguori

>
>  From what I remember from attempting to refactor the DEC bridge though,
> the PCI functions hardcode the domain to 1 currently?
>
> Andreas
>