在 2013-01-09三的 21:24 -0500，Laine Stump写道： > 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.) > glad to hear that, I've committed some patches to support pci-bridge, https://www.redhat.com/archives/libvir-list/2013-January/msg00577.html > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- regards! li guang -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list