Re: [libvirt] Entering freeze for libvirt-1.0.5
[removed libvirt-announce from the cc]
On 04/26/2013 04:11 PM, Daniel Veillard wrote:
On Fri, Apr 26, 2013 at 04:02:51PM +0200, Viktor Mihajlovski wrote:
> On 04/26/2013 10:09 AM, Daniel Veillard wrote:
>> So as discussed earlier this week, I have tagged the release candidate 1
>> of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
>> the FTP at:
>> ftp://libvirt.org/libvirt/
>>
>> We may still push some of the patches needed by Laine to finish the
>> serie started yesterday, but at this point we should focuse our commits
>> on bug fixes and documentation. I will make an rc2 at the beginning of
>> next week and hopefully can push the final version on May 2nd.
>>
>> This passed my own small usage tests, but please give it a try.
>> As usual some feedback on portability issues are really welcome too :-)
> Unfortunately I have to report that commit b33eb0dc seems to have
> broken s390.
> I cannot start guests anymore, error message is
> error: XML error: No PCI buses available
> Will look into it, but any help is welcome.
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)
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.
Jan