qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] q35 chipset support


From: Markus Armbruster
Subject: Re: [Qemu-devel] q35 chipset support
Date: Mon, 18 Jun 2012 15:51:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  writes:
>>
>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>> Hi,
>>>>
>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu 
>>>> and
>>>> seabios trees. On the qemu side, most of the changes revolved around 
>>>> updating
>>>> to use QOM and updates to the memory API. I was also able to drop quite a 
>>>> few
>>>> patches that had already been resolved by the current qemu tree.
>>>>
>>>> The trees seem pretty stable and can be found here:
>>>>
>>>> git://github.com/jibaron/q35-qemu.git
>>>> git://github.com/jibaron/q35-seabios.git
>>>
>>> I'm got the beginnings of a feature page started:
>>>
>>> http://wiki.qemu.org/Features/Q35
>>>
>>> The approach above will not work in a QOM world unfortunately.  We
>>> need to do quite a bit of ground work before adding another chipset.
>>> The biggest task is converting devices to not require an ISA bus since
>>> ICH9 simply doesn't have an ISA bus.
>>
>> Could you explain briefly why use of a software ISA bus construct
>> matters for device models and/or guests?
>
> No, but I can provide a long explanation :-)

Thanks!

> The I440FX has a very basic device topology.  The PCI host is the
> memory controller and there's a PCI device that happens to have the
> SuperI/O chip + a PCI-ISA bridge.  There's no IOMMU and interrupt
> routing is simple.

PC interrupt routing is hardly ever "simple", but I get what you mean ;)

> The Q35 is much more sophisticated.  The PCI-e complex itself can
> present interesting topologies and the legacy PCI bus sits within the
> PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
> chip is not part of it. Rather that's off of a separate bus (the LPC)
> which does not logically reside within the PCI-e complex.

Let's whether I understand.

The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
such bridge exists normally).  Instead, they're connected via LPC.

What I don't get is why that connection can't be modelled as an ISA bus.
Provided by a Systembus-ISA bridge if you like.

> And because there is an IOMMU, this topology is visible to the guest.
>
> Granted, initial Q35 support won't come with an IOMMU, but we will
> need to do this eventually.  There's already non-x86 patches floating
> around.  Normally, I would say we should deal with this later when we
> need an IOMMU but part of the reason this is so hard to fix for the PC
> already is the first set of Q35 patches we merged ages ago that
> introduced the silliness of pc_piix.c.  The first step in cleaning
> this all up is essentially reverting that first set of patches.
>
> 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.

I'm not sufficiently familiar with the first set of Q35 patches to risk
an opinion here...



reply via email to

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