Re: [libvirt] Entering freeze for libvirt-1.0.5

On 04/26/2013 04:35 PM, Ján Tomko wrote: > > The big switch down there lists the architectures/machines that do have > a PCI bus and we disallow adding PCI devices if they don't. > > I thought that any device that qemuAssignDevicePCISlots assigns a PCI > address to would fail at QEMU level with a message about the PCI bus not > found, but it seems this is not the case for the implicit USB controller > -- we assign the address 0:0:1.2 to it, but it shows up > just as '-usb' at the qemu commmand line. > > Are you able to start it after you delete the PCI address from the USB > controller in the XML? (in this case, qemuAssignDevicePCISlots will just > assign it without checking if there's a PCI bus available) > No, the PCI address always get added by default. Specifying model=none doesn't help either.

>> >> Hum, the patch seems to add a big switch about def->os.arch >> in qemuDomainDefPostParse() >> >> + case VIR_ARCH_ALPHA: >> + case VIR_ARCH_PPC: >> + case VIR_ARCH_PPC64: >> + case VIR_ARCH_PPCEMB: >> + case VIR_ARCH_SH4: >> + case VIR_ARCH_SH4EB: >> + addPCIRoot = true; >> + break; >> + default: >> + break; >> >> I smell a case for s390 is needed somehow. > > Not here, it would result in it getting an implicit PCI controller in > the XML, even though it doesn't have a PCI bus. > > The right thing would be to catch all the non-PCI devices we assign an > adddress to. Or we could just assume 1 PCI bus is always available as a > desperate measure not to break anything. I am currently testing the workaround adding a fake PCI root. Will get you posted. If that works it will give us time to come up with a cleaner solution for the next release. I don't want to unconditionally disable PCI for s390 even if it is not implemented in today's QEMUs.