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

On 01/10/13 03:24, Laine Stump wrote: > 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.) Both require support for multiple PCI buses and we assume bus = 0 in quite a few places. I was thinking about putting the number of available buses in qemuDomainPCIAddressSet and adding the set to qemuPCIAddressAsString arguments so we can check if the bus is available and convert the functions with int parameters (slot, function) to use virDomainDeviceInfo or virDevicePCIAddress.