qemu-devel
[Top][All Lists]
Advanced

[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?




reply via email to

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