[Top][All Lists]

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

Re: [Qemu-devel] q35 chipset support

From: Andreas Färber
Subject: Re: [Qemu-devel] q35 chipset support
Date: Mon, 18 Jun 2012 17:36:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

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.

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


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]