On 03/07/2014 03:18 AM, Andreas Färber wrote:
> Am 06.03.2014 04:11, schrieb Alexey Kardashevskiy:
>> Previously libvirt required the first/default PCI bus to have name "pci".
>> Since QEMU can support multiple buses now, libvirt wants "pci.0" now.
>>
>> This removes custom busname and lets QEMU make up default names.



Ufff. Does anyone know any workaround how to tell libvirt to use these
custom names? Since there is no "pci" (and there is "pci.0"), libvirt
cannot put any device onto default PCI bus and I do not see any way to
workaround it in XML, am I missing something here?


>> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
>> ---
>>
>> I tested this with:
>>   -netdev 
>> tap,id=id0,ifname=tapqemu-tap-00,script=ifup.sh,downscript=ifdown.sh \
>>   -device e1000,id=id1,netdev=id0,mac=C0:41:49:4b:00:00 \
>>   -device \
>>   spapr-pci-host-bridge,index=5,id=aikbus \
>>   -netdev tap,id=id2,ifname=tap-1,script=ifup.sh,downscript=ifdown.sh \
>>   -device rtl8139,id=id3,netdev=id2,bus=aikbus.0,mac=C0:41:49:4b:00:01 \
>>   -device spapr-pci-vfio-host-bridge,id=id4,index=10,iommu=4 \
>>
>> This creates a default PCI, an additional emulated PCI bus (named aikbus,
> 
> aikbus.0 for the bus according to example and info qtree, but yeah ;)
> 
>> if I omit the name, it is pci.1 which is also fine) and VFIO bus (which is
>> not in upstream yet but still), this all works fine and I cannot see any 
>> flaw.
>>
>>
>> ---
>>  hw/ppc/spapr_pci.c | 23 ++---------------------
>>  1 file changed, 2 insertions(+), 21 deletions(-)
> 
> Thanks, in absence of Alex applying to qom-next:
> https://github.com/afaerber/qemu-cpu/commits/qom-next
> 
> Andreas
> 


-- 
Alexey

Reply via email to