Re: [Qemu-devel] x86, nops settings result in kernel crash

[Anthony Liguori]

Alan Cox <address@hidden> writes:

> On Thu, 16 Aug 2012 14:45:15 -0400 (EDT)
> Tomas Racek <address@hidden> wrote:
>
>> ----- Original Message -----
>> > On Thu, Aug 16, 2012 at 09:35:12AM -0400, Tomas Racek wrote:
>> > > Hi,
>> > > 
>> > > I am writing a file system test which I execute in qemu with kernel
>> > > compiled from latest git sources and running it causes this error:
>> > > 
>> > > https://bugzilla.kernel.org/show_bug.cgi?id=45971
>> > > 
>> > > It works with v3.5, so I ran git bisect which pointed me to:
>> > > 
>> > > d6250a3f12edb3a86db9598ffeca3de8b4a219e9 x86, nops: Missing break
>> > > resulting in incorrect selection on Intel
>> > > 
>> > > To be quite honest, I don't understand this stuff much but I tried
>> > > to do some debugging and I figured out (I hope) that the crash is
>> > > caused by setting ideal_nops to p6_nops (k8_nops was used before
>> > > the break statement was added).
>> > 
>> > Maybe I overlooked it or maybe it was implied but did you try
>> > reverting
>> > the patch and rerunning your test? Does it work ok then?
>> > 
>> 
>> Yes, if I remove the break statement (introduced by this commit), it works 
>> fine.
>
> What version of qemu is this - do we have qemu bug here I wonder.

>From the cpuinfo, it's 0.15.1.  That's old but not ancient.

I took a brief look at the kernel code here.  The default invocation of
qemu presents an idealistic CPU with a very minimum feature bit set
exposed.  No processor has ever existed with this feature set.

We do this in order to maintain compatibility when migration from Intel
to AMD but also for legacy reasons.

>From the report, using '-cpu host' solves the problem.  '-cpu host'
exposes most of the host CPUID to the guest.

That said, QEMU really doesn't do anything differently depending on what
feature bits are exposed to the guest.  So my guess is that the odd
combination of CPUID bits that are exposed to the guest is confusing the
kernel.

Can you post dmesg from the host kernel?  Perhaps there's instruction
emulation failing in the host KVM?  That would manifest in strange
behavior in the guest.

Regards,

Anthony Liguori

>
> Alan