[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] q35 machine type and libvirt.
From: |
Laine Stump |
Subject: |
Re: [Qemu-devel] q35 machine type and libvirt. |
Date: |
Wed, 27 Feb 2013 13:20:12 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 02/06/2013 02:13 PM, Laine Stump wrote:
> Now that qemu is getting the q35 machine type, libvirt needs to support it.
In an attempt to make sure that libvirt actually does something useful
with qemu's new machine type, I'm revisiting this topic and trying to
get a more thorough understanding.
I've developed my own list of what I *think* are the reasons for wanting
a new machine type in qemu (and from that it should be more apparent
what libvirt needs to do with it), and am wondering how far off the mark
I am:
* Protection against obsolescence (PIIX (pc machine type) is 17 years old (?)
and some OSes may drop support for it).
* Passthrough of PCIe hardware? Is this really an issue? (e.g. the
VFs of a PCIe SRIOV network card can already be passed through as
standard PCI devices)
* Larger bus space? Is this solved even without the new machine type by
simply
supporting the existing pci-bridge device and allowing multiple buses?
* Support for new emulated hardware. (what is important?)
Are any of these misguided thinking on my part? Are there other real advantages
over using the pc-* machine type?
As an adjunct to that, in some conversations people have mentioned the fact
that the Q35 chipset is already out of production, and that supporting
something more recent, like the X58, might be better in the long run. Would the
main advantage of that be supportability? Or are there other concrete
differences in a newer chipset that might by themselves make it worth
considering? (Conversely, would attempting to write the drivers for a newer
chipset just be busywork that only netted a more complex virtual machine but no
useful gains?)
So, based on the above (and whatever other gains are to be had from the new
machine type) what is needed/expected from libvirt? Here's my rough list:
* setup different default buses/controllers/devices based on machine
type (including possibility of using pcie.0 as the root)
* table of fixed locations for certain devices (if present) (again,
based on machine type)
* restrict certain *types* of devices to certain *types* of
slots? (I'm a bit fuzzy on this one, but this has to do with the
"root complex" vs. "endpoint" vs. "integrated endpoint" that Alex
mentioned).
* support some new emulated chipset devices?
* Anything else specific required to passthrough pcie devices?