[Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

The QEMU team is pleased to announce the availability of the 0.12.0-rc1
release.  This is the first release candidate for the 0.12.0 release. 
This release is not intended for production use.

Testing release candidates is a great way to contribute to QEMU and 
improve the quality of the 0.12.0 release.

The current plan is to release a 0.12.0-rc2 on Friday, Dec. 11th 
followed by the final 0.12.0 release on Wednesday, Dec 15th.

For this release candidate, we would appreciate as much testing and 
feedback as possible, particularly the following features which have 
seen a lot of activity since the 0.11.0 release:

  - live migration; especially with non-x86 and complex machine 
configurations
  - block device migration
  - exotic x86 guests that may interact with the BIOS in special ways
  - PXE booting
  - SCSI disk support
  - any tools that depend on parsing monitor output

It can be downloaded from Savannah at:

http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz

Please send testing feedback (positive or negative) to qemu-devel and 
file bugs against the release candidate at:

https://bugs.launchpad.net/qemu

On behalf of the QEMU team, I'd like to thank everyone who contributed
to make this release happen!

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Luiz Capitulino]

On Sun, 06 Dec 2009 16:43:03 -0600
Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:

> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
> release.  This is the first release candidate for the 0.12.0 release. 
> This release is not intended for production use.
> 
> Testing release candidates is a great way to contribute to QEMU and 
> improve the quality of the 0.12.0 release.
> 
> The current plan is to release a 0.12.0-rc2 on Friday, Dec. 11th 
> followed by the final 0.12.0 release on Wednesday, Dec 15th.

 What about patches sent on friday and not merged yet? Like:

http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00462.html

http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00481.html

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

Luiz Capitulino wrote:
> On Sun, 06 Dec 2009 16:43:03 -0600
> Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
>
>   
>> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
>> release.  This is the first release candidate for the 0.12.0 release. 
>> This release is not intended for production use.
>>
>> Testing release candidates is a great way to contribute to QEMU and 
>> improve the quality of the 0.12.0 release.
>>
>> The current plan is to release a 0.12.0-rc2 on Friday, Dec. 11th 
>> followed by the final 0.12.0 release on Wednesday, Dec 15th.
>>     
>
>  What about patches sent on friday and not merged yet? Like:
>
> http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00462.html
>
> http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00481.html
>   

They were too late to make -rc1 but I plan on pulling them in today for 
-rc2 (along with Gerd's default devices patch set).

Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Luiz Capitulino]

On Mon, 07 Dec 2009 07:45:49 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Luiz Capitulino wrote:
> > On Sun, 06 Dec 2009 16:43:03 -0600
> > Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
> >
> >   
> >> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
> >> release.  This is the first release candidate for the 0.12.0 release. 
> >> This release is not intended for production use.
> >>
> >> Testing release candidates is a great way to contribute to QEMU and 
> >> improve the quality of the 0.12.0 release.
> >>
> >> The current plan is to release a 0.12.0-rc2 on Friday, Dec. 11th 
> >> followed by the final 0.12.0 release on Wednesday, Dec 15th.
> >>     
> >
> >  What about patches sent on friday and not merged yet? Like:
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00462.html
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00481.html
> >   
> 
> They were too late to make -rc1 but I plan on pulling them in today for 
> -rc2 (along with Gerd's default devices patch set).

 Excellent, will review Gerd's series shortly.

[Qemu-devel] Re: [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Michael S. Tsirkin]

On Mon, Dec 07, 2009 at 07:45:49AM -0600, Anthony Liguori wrote:
> Luiz Capitulino wrote:
>> On Sun, 06 Dec 2009 16:43:03 -0600
>> Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
>>
>>   
>>> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
>>> release.  This is the first release candidate for the 0.12.0 release. 
>>> This release is not intended for production use.
>>>
>>> Testing release candidates is a great way to contribute to QEMU and  
>>> improve the quality of the 0.12.0 release.
>>>
>>> The current plan is to release a 0.12.0-rc2 on Friday, Dec. 11th  
>>> followed by the final 0.12.0 release on Wednesday, Dec 15th.
>>>     
>>
>>  What about patches sent on friday and not merged yet? Like:
>>
>> http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00462.html
>>
>> http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00481.html
>>   
>
> They were too late to make -rc1 but I plan on pulling them in today for  
> -rc2 (along with Gerd's default devices patch set).
>
> Regards,
>
> Anthony Liguori

I hope this also includes the -global patches currently in staging as
well?

>
>

[Qemu-devel] Re: [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

Michael S. Tsirkin wrote:
> I hope this also includes the -global patches currently in staging as
> well?
>   

There's nothing in staging.

But yes, the -global bits are part of Gerd's default devices series.

Regards,

Anthony Liguori

[Qemu-devel] Re: [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Michael S. Tsirkin]

On Mon, Dec 07, 2009 at 08:36:07AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> I hope this also includes the -global patches currently in staging as
>> well?
>>   
>
> There's nothing in staging.

There isn't?
I fetched:
git://repo.or.cz/qemu/aliguori-queue.git master
and I see:
git log qemu-config.c

commit 8b53d560501d20346377ab836b4071ec7db0ff6e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 24 12:06:28 2009 +0100

    qdev: add command line option to set global defaults for properties.


> But yes, the -global bits are part of Gerd's default devices series.

Cool, thanks!

> Regards,
>
> Anthony Liguori
>

[Qemu-devel] Re: [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

Michael S. Tsirkin wrote:
> On Mon, Dec 07, 2009 at 08:36:07AM -0600, Anthony Liguori wrote:
>   
>> Michael S. Tsirkin wrote:
>>     
>>> I hope this also includes the -global patches currently in staging as
>>> well?
>>>   
>>>       
>> There's nothing in staging.
>>     
>
> There isn't?
>   

s/staging/my local staging/  :-)

I've now pushed.

Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Daniel P. Berrange]

On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
> 
> It can be downloaded from Savannah at:
> 
> http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
> 
> Please send testing feedback (positive or negative) to qemu-devel and 
> file bugs against the release candidate at:

A couple of hotplug issues with the old monitor


It crashes with an assertion failure when hot-plugging without ACPI enabled.
Previously this worked, but that was perhaps just by luck rather than 
design. 

$ /home/berrange/usr/qemu-git/bin/qemu -monitor stdio  -no-acpi
QEMU 0.11.50 monitor - type 'help' for more information
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
qemu: /home/berrange/src/external/qemu/hw/qdev.c:109: qdev_create: Assertion `bus->allow_hotplug' failed.
Aborted (core dumped)


It will also abort when you attempt to add the 28th extra device, but this
isn't a regression - it has always crashed & burned this way.


$ /home/berrange/usr/qemu-git/bin/qemu -monitor stdio  
QEMU 0.11.50 monitor - type 'help' for more information
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 4, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 5, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 6, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 7, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 8, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 9, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 10, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 11, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 12, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 13, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 14, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 15, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 16, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 17, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 18, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 19, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 20, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 21, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 22, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 23, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 24, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 25, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 26, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 27, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 28, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 29, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 30, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
OK domain 0, bus 0, slot 31, function 0
(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
qemu: hardware error: PCI: no devfn available for virtio-blk-pci, all in use

CPU #0:
EAX=000f4242 EBX=00000040 ECX=00000042 EDX=0000428b
ESI=0000000f EDI=00004240 EBP=00006f3e ESP=00006f0a
EIP=0000a8c9 EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES =0040 00000400 0000ffff 00009300
CS =f000 000f0000 0000ffff 00009b0f
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000fcbb0 00000037
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
DR6=ffff0ff0 DR7=00000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
Aborted (core dumped)


In both cases though I'd expect an error to be returned to the monitor
client not an assertion failure


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
>   
>> It can be downloaded from Savannah at:
>>
>> http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
>>
>> Please send testing feedback (positive or negative) to qemu-devel and 
>> file bugs against the release candidate at:
>>     
>
> A couple of hotplug issues with the old monitor
>
>
> It crashes with an assertion failure when hot-plugging without ACPI enabled.
> Previously this worked, but that was perhaps just by luck rather than 
> design. 
>
> $ /home/berrange/usr/qemu-git/bin/qemu -monitor stdio  -no-acpi
> QEMU 0.11.50 monitor - type 'help' for more information
>   

Are you sure you're using 0.12.0-rc1?  The version would be 0.11.91.

Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Daniel P. Berrange]

On Mon, Dec 07, 2009 at 01:43:01PM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
> >  
> >>It can be downloaded from Savannah at:
> >>
> >>http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
> >>
> >>Please send testing feedback (positive or negative) to qemu-devel and 
> >>file bugs against the release candidate at:
> >>    
> >
> >A couple of hotplug issues with the old monitor
> >
> >
> >It crashes with an assertion failure when hot-plugging without ACPI 
> >enabled.
> >Previously this worked, but that was perhaps just by luck rather than 
> >design. 
> >
> >$ /home/berrange/usr/qemu-git/bin/qemu -monitor stdio  -no-acpi
> >QEMU 0.11.50 monitor - type 'help' for more information
> >  
> 
> Are you sure you're using 0.12.0-rc1?  The version would be 0.11.91.

Sorry, that demo was with latest GIT master, but it doesn't matter as it
fails identically on 0.12.0-rc1

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Gerd Hoffmann]

On 12/07/09 19:34, Daniel P. Berrange wrote:
> On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
>>
>> It can be downloaded from Savannah at:
>>
>> http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
>>
>> Please send testing feedback (positive or negative) to qemu-devel and
>> file bugs against the release candidate at:
>
> A couple of hotplug issues with the old monitor
>
>
> It crashes with an assertion failure when hot-plugging without ACPI enabled.
> Previously this worked, but that was perhaps just by luck rather than
> design.

"worked" as in "guest actually sees the new device (without reboot)" or
"worked" as in "qemu didn't abort" ?

cheers,
   Gerd

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Daniel P. Berrange]

On Tue, Dec 08, 2009 at 11:40:54AM +0100, Gerd Hoffmann wrote:
> On 12/07/09 19:34, Daniel P. Berrange wrote:
> >On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
> >>
> >>It can be downloaded from Savannah at:
> >>
> >>http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
> >>
> >>Please send testing feedback (positive or negative) to qemu-devel and
> >>file bugs against the release candidate at:
> >
> >A couple of hotplug issues with the old monitor
> >
> >
> >It crashes with an assertion failure when hot-plugging without ACPI 
> >enabled.
> >Previously this worked, but that was perhaps just by luck rather than
> >design.
> 
> "worked" as in "guest actually sees the new device (without reboot)" or
> "worked" as in "qemu didn't abort" ?

The latter. The guest does not see it, but it at least does not abort.
It is the 'does not abort' behaviour I'm interested in - quite OK with
this returning an error to the monitor client when acpi is disabled.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On 12/08/09 11:52, Daniel P. Berrange wrote:
> On Tue, Dec 08, 2009 at 11:40:54AM +0100, Gerd Hoffmann wrote:
>> "worked" as in "guest actually sees the new device (without reboot)" or
>> "worked" as in "qemu didn't abort" ?
>
> The latter. The guest does not see it, but it at least does not abort.
> It is the 'does not abort' behaviour I'm interested in - quite OK with
> this returning an error to the monitor client when acpi is disabled.

Does the attached patch fix it for you?

cheers,
   Gerd


[-- Attachment #2: 0001-fix-pci-hotplug.patch --]
[-- Type: text/plain, Size: 1452 bytes --]

>From c87a20bc8c0347770f55c8267ec10667cd2ba24c Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Tue, 8 Dec 2009 13:50:16 +0100
Subject: [PATCH] fix pci hotplug


Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/pci-hotplug.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 081d6d1..7e5c51d 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -40,7 +40,18 @@ static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
                                        const char *opts_str)
 {
     QemuOpts *opts;
-    int ret;
+    PCIBus *bus;
+    int ret, devfn;
+
+    bus = pci_get_bus_devfn(&devfn, devaddr);
+    if (!bus) {
+        monitor_printf(mon, "Invalid PCI device address %s\n", devaddr);
+        return NULL;
+    }
+    if (!((BusState*)bus)->allow_hotplug) {
+        monitor_printf(mon, "PCI bus doesn't support hotplug\n");
+        return NULL;
+    }
 
     opts = qemu_opts_parse(&qemu_net_opts, opts_str ? opts_str : "", NULL);
     if (!opts) {
@@ -179,6 +190,10 @@ static PCIDevice *qemu_pci_hot_add_storage(Monitor *mon,
         monitor_printf(mon, "Invalid PCI device address %s\n", devaddr);
         return NULL;
     }
+    if (!((BusState*)bus)->allow_hotplug) {
+        monitor_printf(mon, "PCI bus doesn't support hotplug\n");
+        return NULL;
+    }
 
     switch (type) {
     case IF_SCSI:
-- 
1.6.5.2

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On 12/08/09 13:52, Gerd Hoffmann wrote:
>> The latter. The guest does not see it, but it at least does not abort.
>> It is the 'does not abort' behaviour I'm interested in - quite OK with
>> this returning an error to the monitor client when acpi is disabled.
>
> Does the attached patch fix it for you?

One more fix for the "hw_error() when slots full" case.

cheers,
   Gerd

[-- Attachment #2: 0001-pci-don-t-hw_error-when-no-slot-is-available.patch --]
[-- Type: text/plain, Size: 2007 bytes --]

>From 1c1de5c577a3241df4fb52cfdf15e97af9283caa Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Tue, 8 Dec 2009 14:05:11 +0100
Subject: [PATCH] pci: don't hw_error() when no slot is available.


Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/pci.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 4f662b7..404eead 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -580,11 +580,13 @@ static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
             if (!bus->devices[devfn])
                 goto found;
         }
-        hw_error("PCI: no devfn available for %s, all in use\n", name);
+        qemu_error("PCI: no devfn available for %s, all in use\n", name);
+        return NULL;
     found: ;
     } else if (bus->devices[devfn]) {
-        hw_error("PCI: devfn %d not available for %s, in use by %s\n", devfn,
+        qemu_error("PCI: devfn %d not available for %s, in use by %s\n", devfn,
                  name, bus->devices[devfn]->name);
+        return NULL;
     }
     pci_dev->bus = bus;
     pci_dev->devfn = devfn;
@@ -625,6 +627,9 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
     pci_dev = do_pci_register_device(pci_dev, bus, name, devfn,
                                      config_read, config_write,
                                      PCI_HEADER_TYPE_NORMAL);
+    if (pci_dev == NULL) {
+        hw_error("PCI: can't register device\n");
+    }
     return pci_dev;
 }
 static target_phys_addr_t pci_to_cpu_addr(target_phys_addr_t addr)
@@ -1376,6 +1381,8 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
     pci_dev = do_pci_register_device(pci_dev, bus, base->name, devfn,
                                      info->config_read, info->config_write,
                                      info->header_type);
+    if (pci_dev == NULL)
+        return -1;
     rc = info->init(pci_dev);
     if (rc != 0)
         return rc;
-- 
1.6.5.2

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Daniel P. Berrange]

On Tue, Dec 08, 2009 at 02:07:29PM +0100, Gerd Hoffmann wrote:
> On 12/08/09 13:52, Gerd Hoffmann wrote:
> >>The latter. The guest does not see it, but it at least does not abort.
> >>It is the 'does not abort' behaviour I'm interested in - quite OK with
> >>this returning an error to the monitor client when acpi is disabled.
> >
> >Does the attached patch fix it for you?
> 
> One more fix for the "hw_error() when slots full" case.

Yes, the combination of those two patches fix both problems


(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
PCI bus doesn't support hotplug
failed to add file=/home/berrange/mcdboot.img,if=virtio


(qemu) pci_add pci_addr=auto storage file=/home/berrange/mcdboot.img,if=virtio
PCI: no devfn available for virtio-blk-pci, all in use
failed to add file=/home/berrange/mcdboot.img,if=virtio

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Qemu-devel] [PULL] pci compliance fixes

[Michael S. Tsirkin]

Anthony, two patchsets with pci compliance fixes are now on my pci
tree. They fix WHQL errors. We should also consider them for 0.12.
I think that msi function mask fix is definitely safe for that,
interrupt status fixes might be slightly more risky as they affect
all devices.

The following changes since commit 5d7ff5bbde21858b43af38e7cb5cae59bd4668ad:
  Andreas Faerber (1):
        TCG: Mac OS X support for ppc64 target

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony

Michael S. Tsirkin (5):
      msix: macro rename for function mask support
      msix: function mask support
      pci: prepare irq code for interrupt state
      pci: interrupt status bit implementation
      pci: interrupt disable bit support

 hw/msix.c |   74 +++++++++++++++++++++----------
 hw/pci.c  |  144 +++++++++++++++++++++++++++++++++++++++++++++++++++++--------
 hw/pci.h  |    4 +-
 3 files changed, 179 insertions(+), 43 deletions(-)
-- 
MST

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Ian Molton]

Anthony Liguori wrote:
> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
> release.  This is the first release candidate for the 0.12.0 release.
> This release is not intended for production use.

What git tree should I rebase my patches onto (for the next release) ?

Thanks,

-Ian

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Daniel P. Berrange]

On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
> release.  This is the first release candidate for the 0.12.0 release. 
> This release is not intended for production use.
> 
> Testing release candidates is a great way to contribute to QEMU and 
> improve the quality of the 0.12.0 release.
> 
> The current plan is to release a 0.12.0-rc2 on Friday, Dec. 11th 
> followed by the final 0.12.0 release on Wednesday, Dec 15th.
> 
> For this release candidate, we would appreciate as much testing and 
> feedback as possible, particularly the following features which have 
> seen a lot of activity since the 0.11.0 release:
> 
>  - live migration; especially with non-x86 and complex machine 
> configurations
>  - block device migration
>  - exotic x86 guests that may interact with the BIOS in special ways
>  - PXE booting
>  - SCSI disk support
>  - any tools that depend on parsing monitor output

There's a small bug in SCSI drive hotplug where QEMU is not assigning
unique block device names when you leave the name unspecified

$ /home/berrange/usr/qemu-0.12/bin/qemu -vnc :1 -monitor stdio -device lsi
QEMU 0.11.91 monitor - type 'help' for more information
(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
OK bus 0, unit 0
(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
OK bus 0, unit 1
(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
OK bus 0, unit 2
(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
OK bus 0, unit 3
(qemu) info block
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]
scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
(qemu) 


Notice they are all 'scsi0-hd0', instead of scsi0-hd1, scsi0-hd2, etc

(Ignore the fact that i attached the same underlying file many times :-)

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On 12/09/09 17:56, Daniel P. Berrange wrote:
> There's a small bug in SCSI drive hotplug where QEMU is not assigning
> unique block device names when you leave the name unspecified
>
> $ /home/berrange/usr/qemu-0.12/bin/qemu -vnc :1 -monitor stdio -device lsi
> QEMU 0.11.91 monitor - type 'help' for more information
> (qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> OK bus 0, unit 0
> (qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> OK bus 0, unit 1
> (qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> OK bus 0, unit 2
> (qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> OK bus 0, unit 3
> (qemu) info block
> ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
> floppy0: type=floppy removable=1 locked=0 [not inserted]
> sd0: type=floppy removable=1 locked=0 [not inserted]
> scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
> scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
> scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
> scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 drv=raw encrypted=0
> (qemu)
>
> Notice they are all 'scsi0-hd0', instead of scsi0-hd1, scsi0-hd2, etc

Fix attached.

Note that the whole auto-naming only works reliable if you limit 
yourself to a single scsi bus (in any qemu version out there).  I 
strongly recommend to simply name the drives yourself using id=<name>. 
Works in 0.12 and IIRC in 0.11 too.

cheers,
   Gerd


[-- Attachment #2: 0001-scsi-drive-hotplug.patch --]
[-- Type: text/plain, Size: 777 bytes --]

>From bd87046b51df2c15e5017e79155045a4e2b7f83b Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 10 Dec 2009 10:13:59 +0100
Subject: [PATCH] scsi drive hotplug

---
 hw/pci-hotplug.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 7e5c51d..9e8e6ed 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -93,6 +93,7 @@ static int scsi_hot_add(DeviceState *adapter, DriveInfo *dinfo, int printinfo)
      */
     dinfo->unit = qemu_opt_get_number(dinfo->opts, "unit", -1);
     scsidev = scsi_bus_legacy_add_drive(scsibus, dinfo, dinfo->unit);
+    dinfo->unit = scsidev->id;
 
     if (printinfo)
         qemu_error("OK bus %d, unit %d\n", scsibus->busnr, scsidev->id);
-- 
1.6.5.2

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Daniel P. Berrange]

On Thu, Dec 10, 2009 at 10:22:24AM +0100, Gerd Hoffmann wrote:
> On 12/09/09 17:56, Daniel P. Berrange wrote:
> >There's a small bug in SCSI drive hotplug where QEMU is not assigning
> >unique block device names when you leave the name unspecified
> >
> >$ /home/berrange/usr/qemu-0.12/bin/qemu -vnc :1 -monitor stdio -device lsi
> >QEMU 0.11.91 monitor - type 'help' for more information
> >(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> >OK bus 0, unit 0
> >(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> >OK bus 0, unit 1
> >(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> >OK bus 0, unit 2
> >(qemu) drive_add 0:0:4  file=/home/berrange/mcdboot.img,if=scsi
> >OK bus 0, unit 3
> >(qemu) info block
> >ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
> >floppy0: type=floppy removable=1 locked=0 [not inserted]
> >sd0: type=floppy removable=1 locked=0 [not inserted]
> >scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 
> >drv=raw encrypted=0
> >scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 
> >drv=raw encrypted=0
> >scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 
> >drv=raw encrypted=0
> >scsi0-hd0: type=hd removable=0 file=/home/berrange/mcdboot.img ro=1 
> >drv=raw encrypted=0
> >(qemu)
> >
> >Notice they are all 'scsi0-hd0', instead of scsi0-hd1, scsi0-hd2, etc
> 
> Fix attached.
> 
> Note that the whole auto-naming only works reliable if you limit 
> yourself to a single scsi bus (in any qemu version out there).  I 
> strongly recommend to simply name the drives yourself using id=<name>. 
> Works in 0.12 and IIRC in 0.11 too.

Yes we are going to start explicitly naming all the QEMU devices
that libvirt creates. I just want this fix for existing released
libvirt which doesn't name devices.


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

The QEMU team is pleased to announce the availability of the 0.12.0-rc2
release.  This is the second release candidate for the 0.12.0 release.
This release is not intended for production use.

Testing release candidates is a great way to contribute to QEMU and
improve the quality of the 0.12.0 release.

The current plan is to release 0.12.0 on Friday, Dec 18th.  Depending on 
the severity of bug fixes we get between now and then, we may do another 
release candidate in the middle of the week.

For this release candidate, we would appreciate as much testing and
feedback as possible, particularly the following features which have
seen a lot of activity since the 0.11.0 release:

  - live migration; especially with non-x86 and complex machine
configurations
  - block device migration
  - exotic x86 guests that may interact with the BIOS in special ways
  - PXE booting
  - SCSI disk support
  - any tools that depend on parsing monitor output

It can be downloaded from Savannah at:

http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc2.tar.gz

Please send testing feedback (positive or negative) to qemu-devel and
file bugs against the release candidate at:

https://bugs.launchpad.net/qemu

A detailed change log since 0.12.0-rc1 is included below.

On behalf of the QEMU team, I'd like to thank everyone who contributed
to make this release happen!

version 0.12.0-rc2:

   - v2: properly save kvm system time msr registers (Glauber Costa)
   - convert more monitor commands to qmp (Luiz Capitulino)
   - vnc: fix capslock tracking logic. (Gerd Hoffmann)
   - QemuOpts: allow larger option values. (Gerd Hoffmann)
   - scsi: fix drive hotplug. (Gerd Hoffmann)
   - pci: don't hw_error() when no slot is available. (Gerd Hoffmann)
   - pci: don't abort() when trying to hotplug with acpi off. (Gerd 
Hoffmann)
   - allow default devices to be implemented in config file (Gerd Hoffman)
   - vc: colorize chardev title line with blue background. (Gerd Hoffmann)
   - chardev: make chardevs specified in config file work. (Gerd Hoffmann)
   - qdev: also match bus name for global properties (Gerd Hoffmann)
   - qdev: add command line option to set global defaults for 
properties. (Gerd H
offmann)
   - kvm: x86: Save/restore exception_index (Jan Kiszka)
   - qdev: Replace device names containing whitespace (Markus Armbruster)
   - fix rtc-td-hack on host without high-res timers (Gleb Natapov)
   - virtio: verify features on load (Michael S. Tsirkin)
   - vmware_vga: add rom file so that it boots. (Dave Airlie)
   - Do not abort on qemu_malloc(0) in production builds (Anthony Liguori)
   - Fix ARM userspace strex implementation. (Paul Brook)
   - qemu: delete rule target on error (Michael S. Tsirkin)
   - QMP: add human-readable description to error response (Markus 
Armbruster)
   - convert more monitor commands to QError (Markus Armbruster)
   - monitor: Fix double-prompt after "change vnc passwd BLA" (Markus 
Armbruster)
   - monitor: do_cont(): Don't ask for passwords (Luiz Capitulino)
   - monitor: Introduce 'block_passwd' command (Luiz Capitulino)
   - pci: interrupt disable bit support (Michael S. Tsirkin)
   - pci: interrupt status bit implementation (Michael S. Tsirkin)
   - pci: prepare irq code for interrupt state (Michael S. Tsirkin)
   - msix: function mask support (Michael S. Tsirkin)
   - msix: macro rename for function mask support (Michael S. Tsirkin)
   - cpuid: Fix multicore setup on Intel (Andre Przywara)
   - kvm: x86: Fix initial kvm_has_msr_star (Jan Kiszka)
   - Update OpenBIOS images to r640 (Aurelien Jarno)

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Artyom Tarasenko]

2009/12/14 Anthony Liguori <aliguori@linux.vnet.ibm.com>:
> The current plan is to release 0.12.0 on Friday, Dec 18th.  Depending on the
> severity of bug fixes we get between now and then, we may do another release
> candidate in the middle of the week.

I see that the carry flag fix for sparc is included. Are you planning
to include the rest of my sparc/scsi patches? They are not as drastic
as the carry fix, so they shouldn't break something which isn't
already broken. On the other hand, the ability to boot Solaris/sparc
kernel may be important for some users.


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

Artyom Tarasenko wrote:
> 2009/12/14 Anthony Liguori <aliguori@linux.vnet.ibm.com>:
>   
>> The current plan is to release 0.12.0 on Friday, Dec 18th.  Depending on the
>> severity of bug fixes we get between now and then, we may do another release
>> candidate in the middle of the week.
>>     
>
> I see that the carry flag fix for sparc is included. Are you planning
> to include the rest of my sparc/scsi patches? They are not as drastic
> as the carry fix, so they shouldn't break something which isn't
> already broken. On the other hand, the ability to boot Solaris/sparc
> kernel may be important for some users.
>   

It's up to Blue Swirl to decide about the sparc patches.  The SCSI 
Inquiry fix is reasonable but it missed the -rc2 deadline.  I'll queue 
it for final release.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Blue Swirl]

On Mon, Dec 14, 2009 at 4:20 PM, Anthony Liguori
<aliguori@linux.vnet.ibm.com> wrote:
> Artyom Tarasenko wrote:
>>
>> 2009/12/14 Anthony Liguori <aliguori@linux.vnet.ibm.com>:
>>
>>>
>>> The current plan is to release 0.12.0 on Friday, Dec 18th.  Depending on
>>> the
>>> severity of bug fixes we get between now and then, we may do another
>>> release
>>> candidate in the middle of the week.
>>>
>>
>> I see that the carry flag fix for sparc is included. Are you planning
>> to include the rest of my sparc/scsi patches? They are not as drastic
>> as the carry fix, so they shouldn't break something which isn't
>> already broken. On the other hand, the ability to boot Solaris/sparc
>> kernel may be important for some users.
>>
>
> It's up to Blue Swirl to decide about the sparc patches.  The SCSI Inquiry
> fix is reasonable but it missed the -rc2 deadline.  I'll queue it for final
> release.

The FDC fix should be OK. Technically AFX patch adds new
functionality, but very limited.

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Avi Kivity]

On 12/14/2009 04:06 PM, Anthony Liguori wrote:
> The QEMU team is pleased to announce the availability of the 0.12.0-rc2
> release.  This is the second release candidate for the 0.12.0 release.
> This release is not intended for production use.

I'm missing the tag for this release?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Anthony Liguori]

Avi Kivity wrote:
> On 12/14/2009 04:06 PM, Anthony Liguori wrote:
>> The QEMU team is pleased to announce the availability of the 0.12.0-rc2
>> release.  This is the second release candidate for the 0.12.0 release.
>> This release is not intended for production use.
>
> I'm missing the tag for this release?

Sorry, should be there now.  Forgot to push the tag explicitly.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU

[Ryan Harper]

* Anthony Liguori <aliguori@linux.vnet.ibm.com> [2009-12-14 08:33]:
> The QEMU team is pleased to announce the availability of the 0.12.0-rc2
> release.  This is the second release candidate for the 0.12.0 release.
> This release is not intended for production use.
> 
> Testing release candidates is a great way to contribute to QEMU and
> improve the quality of the 0.12.0 release.
> 
> The current plan is to release 0.12.0 on Friday, Dec 18th.  Depending on 
> the severity of bug fixes we get between now and then, we may do another 
> release candidate in the middle of the week.
> 
> For this release candidate, we would appreciate as much testing and
> feedback as possible, particularly the following features which have
> seen a lot of activity since the 0.11.0 release:
> 
>  - live migration; especially with non-x86 and complex machine
> configurations
>  - block device migration
>  - exotic x86 guests that may interact with the BIOS in special ways
>  - PXE booting
>  - SCSI disk support
>  - any tools that depend on parsing monitor output
> 
> It can be downloaded from Savannah at:
> 
> http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc2.tar.gz

0.12.0-rc2 has some issues with WinXP.64 install.  It hangs early during
the install with trying to start Windows.  No further progress is made
and it chews 100% cpu. 

This seems to be kvm module version related.  On up-to-date Fedora 11.64
install 0.12.0-rc1 works, -rc2 doesn't  Git bisect between -rc1 and rc2
points to:

commit 066263f37701687c64af9d8825e3376d069ebfd4
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Mon Dec 7 11:58:02 2009 +0100

cpuid: Fix multicore setup on Intel


Reverting this fixes the problem.

On older kvm modules (2.6.28 from Ubuntu Jaunty) I can't seem to find
any version of recent qemu that works with winxp.64 install.  Switching
to kvm-kmod packages:

2.6.32 modules work fine with 0.12.0-rc2, no issues at all

2.6.30 modules fail, reverting the above commit doesn't help, seems to
be in the same boat as 2.6.28 modules

2.6.31.5 (roughly equivalent to Fedora11 modules) work on -rc1, fail on
rc2, reverting above commit fixes -rc2.

Maybe some other folks are seeing this issue and we can track down what
the real issue is.

> https://bugs.launchpad.net/qemu

Filed https://bugs.launchpad.net/qemu/+bug/497273


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com