[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 0/2] add qemu machine type q35 support



在 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 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.)
> 

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 redhat com
> https://www.redhat.com/mailman/listinfo/libvir-list

-- 
regards!
li guang



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]