[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



On 01/14/2013 12:32 PM, Ján Tomko wrote:
> 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.

I think much of this functionality needs to go into util/virpci.c so
that it can be used by multiple drivers. Anything in util/virpci.c can't
use datatypes from the conf directory. Perhaps we need a simple PCI
address type that's defined in virpci.h and used by everything else. (I
remember looking at this briefly quite a while back, but don't remember
the results).



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