On 01/08/2013 10:15 PM, Doug Goldstein wrote: > On Tue, Jan 8, 2013 at 8:35 PM, liguang <lig.fnst@xxxxxxxxxxxxxx> 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.) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list