lkml.org 
[lkml]   [2012]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Qemu-devel] x86, nops settings result in kernel crash
----- Original Message -----
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > On Thu, 16 Aug 2012 14:45:15 -0400 (EDT)
> > Tomas Racek <tracek@redhat.com> 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've just upgraded my distribution so I tried qemu 1.0.1 which has the same behaviour as the former version.

>
> 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.

Well, I've added some debug statements to the code:

void __init arch_init_ideal_nops(void)
{
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_INTEL:
/*
* Due to a decoder implementation quirk, some
* specific Intel CPUs actually perform better with
* the "k8_nops" than with the SDM-recommended NOPs.
*/
if (boot_cpu_data.x86 == 6 &&
boot_cpu_data.x86_model >= 0x0f &&
boot_cpu_data.x86_model != 0x1c &&
boot_cpu_data.x86_model != 0x26 &&
boot_cpu_data.x86_model != 0x27 &&
boot_cpu_data.x86_model < 0x30) {
printk("NOPS: Option 1\n");
ideal_nops = k8_nops;
} else if (boot_cpu_has(X86_FEATURE_NOPL)) {
printk("NOPS: Option 2\n");
ideal_nops = p6_nops;
} else {
printk("NOPS: Option 3\n");
#ifdef CONFIG_X86_64
ideal_nops = k8_nops;
#else
ideal_nops = intel_nops;
#endif
}
break;
default:
#ifdef CONFIG_X86_64
ideal_nops = k8_nops;
#else
if (boot_cpu_has(X86_FEATURE_K8))
ideal_nops = k8_nops;
else if (boot_cpu_has(X86_FEATURE_K7))
ideal_nops = k7_nops;
else
ideal_nops = intel_nops;
#endif
}
}
This gives me Option 1 with "-cpu host" and Option 2 without.

> 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.

dmesg is in the attachment (qemu ran without "-cpu" argument). If I add "-cpu host" I get this:

[ 1046.112320] kvm: 5938: cpu0 unhandled rdmsr: 0x345
[ 1046.114998] kvm: 5938: cpu0 unhandled wrmsr: 0x680 data 0
[ 1046.115000] kvm: 5938: cpu0 unhandled wrmsr: 0x6c0 data 0
[ 1046.115002] kvm: 5938: cpu0 unhandled wrmsr: 0x681 data 0
[ 1046.115004] kvm: 5938: cpu0 unhandled wrmsr: 0x6c1 data 0
[ 1046.115005] kvm: 5938: cpu0 unhandled wrmsr: 0x682 data 0
[ 1046.115007] kvm: 5938: cpu0 unhandled wrmsr: 0x6c2 data 0
[ 1046.115009] kvm: 5938: cpu0 unhandled wrmsr: 0x683 data 0
[ 1046.115010] kvm: 5938: cpu0 unhandled wrmsr: 0x6c3 data 0
[ 1046.115012] kvm: 5938: cpu0 unhandled wrmsr: 0x684 data 0
[ 1046.115013] kvm: 5938: cpu0 unhandled wrmsr: 0x6c4 data 0


Regards,

Tomas

>
> Regards,
>
> Anthony Liguori
>
> >
> > Alan
>
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2012-08-17 10:21    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site