[libvirt] Preferred CPU model not allowed by hypervisor

[Jared]

On 07/21/2012 08:06 PM, Andrew Cathrow wrote:
> Have a look here
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=804224

Thanks, Andrew.  That's definitely it.  I upgraded to qemu 1.1.1 and it now
boots with modern CPU support.

Appreciate the quick response.

I did run into another problem after making this change, though it's not
related to my original problem.  Wanted to mention it, though, in case
anyone else runs into it:

Once I made this change, with the previous CPU definition I was using
libvirt/qemu booted CentOS 6.3 with "-cpu Westmere" (plus a bunch of
individual features).  When this happened, CentOS would will hang shortly
into the bootup process, as soon as it detects the CPU.  Here are the last
few lines I get before the hang:

Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel Westmere E56xx/L56xx/X56xx (Nehalem-C) stepping 01
Performance Events: Westmere events, Intel PMU driver.
... version:                2
... bit width:              48
... generic registers:      4
... value mask:             0000ffffffffffff
... max period:             000000007fffffff
... fixed-purpose events:   3
... event mask:             000000070000000f
NMI watchdog enabled, takes one hw-pmu counter.

If I set CPU=Nehalem and leave all other features in tact, and also add in
the aes feature (which I think is the only difference between the two
definition-wise), CentOS boots perfectly fine.

There's clearly a bug here somewhere but I honestly have no idea where it
lies.  Setting CPU to Nehalem (which I planned to do anyway) is an easy
workaround for me, so I'm not going to pursue this any further.  If anyone
does want to follow up on this, though, let me know and I'll be happy to
assist where possible.

P.S.  As I was typing this I got one additional line on the console after a
few minutes:

Booting Node   0, Processors  #1 Ok.

Then, after a few more minutes I got a proper kernel dump:

BUG: soft lockup - CPU#0 stuck for 67s! [swapper:1]
Modules linked in:
CPU 0
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.32-279.el6.x86_64 #1 Bochs Bochs
<SNIP>

I'll spare everyone the call trace details, but again, if anyone's
interested in pursuing this just let me know and I'll be happy to provide
all the details.


-- 
Jared