Re: [libvirt] [PATCH 0/2] add qemu machine type q35 support
On 01/08/2013 10:15 PM, Doug Goldstein wrote:
On Tue, Jan 8, 2013 at 8:35 PM, liguang
<lig.fnst(a)cn.fujitsu.com> wrote:
> qemu-1.3 added machine type q35,
> changelog said:
> Added Intel Q35 chipset as a new machine type,
> '--machine q35'. Adds PCIe support. Requires an updated SeaBIOS (bios.bin),
> and '-acpitable file=/seabios-path/q35-acpi-dsdt.aml' to run.
> so add q35 support for libvirt.
>
> src/conf/device_conf.c | 8 +++++++-
> src/conf/device_conf.h | 1 +
> src/conf/domain_conf.c | 1 +
> src/conf/domain_conf.h | 1 +
> src/qemu/qemu_capabilities.c | 11 +++++++++++
> src/qemu/qemu_capabilities.h | 1 +
> src/qemu/qemu_command.c | 8 +++-
> 7 files changed, 29 insertions(+), 2 deletions(-)
>
I'd personally NACK this series for the time being. Per the qemu
maintainers, q35 isn't really fully ready until 1.4. They're actively
in the process of hashing out the machine type which will be exposed
on the command line and via QMP so I think we really need to wait
until that lands in upstream's repo before we add code for it in
libvirt.
In addition there is the issue that libvirt currently makes assumptions
about the bus topology of guests, and assigns pci addresses to guest
devices accordingly. Beyond the basic layout of buses present on the
machine, certain addresses are reserved/used for certain default devices
(e.g. the first video device). The q35 machine type will have a
different topology, so the default addresses of these basic devices may
(will? haven't looked at the details yet) change, and different
addresses will be available for assigning to additional guest pci
devices. (This assumption was actually already a problem, because
libvirt currently incorrectly assumes the default addresses and bus
layout even for non-x86 machinetypes.)
To properly solve this problem, libvirt will need a method of learning
the topology and default device address assignment for each machine type
during capabilities discovery, and honor that information (rather than
just making decisions based on assumptions) during guest device assignment.
I'm already working with someone from qemu on a design and patches to
implement this functionality, so to avoid duplication of effort, you
should wait to see what that looks like before you do any more work in
this area. (A colleague has also been working on PCI bridge support,
which has the potential to conflict with the PCI-e/q35 work if not done
in a coordinated fashion, so you may want to take a wait-and-see
approach there as well.)