From: Markus Armbruster <armbru@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: mst@redhat.com, jan.kiszka@siemens.com,
Jason Baron <jbaron@redhat.com>,
qemu-devel@nongnu.org, yamahata@valinux.co.jp,
alex.williamson@redhat.com
Subject: Re: [Qemu-devel] q35 chipset support
Date: Mon, 18 Jun 2012 15:51:07 +0200 [thread overview]
Message-ID: <m3ipeoiv90.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <4FDB77C9.6020901@codemonkey.ws> (Anthony Liguori's message of "Fri, 15 Jun 2012 12:58:33 -0500")
Anthony Liguori <anthony@codemonkey.ws> writes:
> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>> Anthony Liguori<anthony@codemonkey.ws> 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...
next prev parent reply other threads:[~2012-06-18 13:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-14 19:54 [Qemu-devel] q35 chipset support Jason Baron
2012-06-14 20:16 ` Anthony Liguori
2012-06-15 7:04 ` Markus Armbruster
2012-06-15 17:58 ` Anthony Liguori
2012-06-17 8:25 ` Michael S. Tsirkin
2012-06-18 14:16 ` Anthony Liguori
2012-06-18 14:35 ` Michael S. Tsirkin
2012-06-18 15:15 ` Anthony Liguori
2012-06-18 16:04 ` Jason Baron
2012-06-18 13:51 ` Markus Armbruster [this message]
2012-06-18 14:05 ` Anthony Liguori
2012-06-18 20:36 ` Jason Baron
2012-06-18 21:15 ` Anthony Liguori
2012-06-18 14:20 ` Michael S. Tsirkin
2012-06-18 14:22 ` Anthony Liguori
2012-06-18 14:37 ` Michael S. Tsirkin
2012-06-18 15:36 ` Andreas Färber
2012-06-18 15:45 ` Anthony Liguori
2012-06-15 17:57 ` Jason Baron
2012-06-15 17:59 ` Anthony Liguori
2012-06-18 13:52 ` Markus Armbruster
2012-06-18 14:38 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ipeoiv90.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=jbaron@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.