| Summary: | Kernel panic on qemux86-64 when using runqemu kvm and cpu host | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Kernel | Reporter: | Stefan Stanacar <sstncr> |
| Component: | linux-yocto | Assignee: | Richard Purdie <richard.purdie> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | alexandru.damian, bruce.ashfield, cristian.iorga, jessica.zhang, ning.zhang, raj.khem, richard.purdie, sgw, yi.zhao |
| Version: | 1.4 | ||
| Target Milestone: | 1.5 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | release note for 1.4 | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Stefan Stanacar
2013-02-19 13:48:32 UTC
Scott, can you please have a look an runqemu and whether "-cpu host" is the right option to be using here? Hi Stefan. Can you please explain to me the rationale behind your observations? Paravirtualization is not directly related to -cpu host option, as far as I know. That is one thing. The other thing is this used to work, so clearly it is a regression. Regards, Cristian Hi, is there an estimate when this bug will be fixed? The fact that qemux86-64 machines cannot be run with KVM impacts the performance (boot time is 2x longer), therefore impacting during the development testing. Darren is right, I got a root cause. Patch coming up shortly. This is caused by a restricted instruction issued on CPU type. Patch submitted that sets CPU type to qemu on all targets, and thus avoids using model-specific registers under emulation. Hi Alex, I might be wrong, and I need more time to investigate, but I don't agree with the fix you proposed for this issue. What you propose is just a step back from how qemu should optimally work, meaning exporting "-cpu host". That's one thing. Another thing is the described issue seems to be specific to some kernels on the host. For example, I checked with LaurP and AlexG and thes issue is: - reproducible on Ubuntu 12.10 with kernel 3.5.0.27 and Fedora Core 18 with kernel 3.8.5. - not reproducible with Ubuntu 12.04 with kernel 3.2.x (need to check the exact details with LaurP). This issue needs more investigation. Regards, Cristian Where are we with this? Is it still reproducing? As of 676fd3f394a0c0576b63c77ed2184bf5f42c29b6 I still get the same general protection fault for: runqemu qemux86-64 core-image-sato kvm Hi Stefan, Can you please state the host OS for running qemu? I have noticed that: On Ubuntu 12.04 x86-64 the issue is not reproducible. On Ubuntu 12.10 x86-64 the issue is reproducible. Regards, Cristian It's the same OS as in my first comment: Fedora 18 x86-64. In the meantime kernel went from 3.8.5. to 3.9.4-200.fc18.x86_64 Ping? I still see this on poky master:67f76e6fc2d8476bdaaf500432198670b883138a, Fedora 18 3.9.6-200.fc18.x86_64 Hi, I found this bug can be reproduced on Ubuntu 13.04. But it can not be reproduced on Ubuntu 12.04. Poky is master eaa5df34af42b6a37f6506847d0f3ef6ba0d298a This should be resolved via the updated runqemu options. If this bug can be reproduced with the runqemu script, please reopen. This issue still happens on 1.5 M5 rc1. This isn't fixed as of latest master 63cd03b80c3eb5b4b88774e44a4ed2cf0905f094, and I haven't seen anything going in related to this. (see earlier comments about distro/kernel versions where the panic shows up) I know this bug has been in set in REVIEW for a looong time (probably because of comment #5) but that patch has never been merged and IIRC there were some comments on the list at that time, so nothing changed here. Darren are we missing something? You said something about "updated runqemu options"... ) Stefan, how are you running the test? Is the runqemu command used? Yup: runqemu qemux86-64 core-image-minimal kvm Bruce, I'm hoping with your work in the virtualisation space you have a better idea than we do of what we should be passing to qemu here. Currently -cpu host is used which gets a backtrace from perf for me too. Other options appear to be qemu64, kvm64, kvm32 and qemu32. $ /qemu-system-x86_64 -cpu help x86 qemu64 QEMU Virtual CPU version 1.5.0 x86 kvm64 Common KVM processor x86 qemu32 QEMU Virtual CPU version 1.5.0 x86 kvm32 Common 32-bit KVM processor x86 host KVM processor with all supported host features (only available in KVM mode) which one do we want and why? qemu64 and kvm64 are roughly the same, in particular if you are launching with
the -enable-kvm. The latter is supposed to offer a consistent base and capability
set to the VMs, the former is often the default and will present a similar ... but not
as tailored set of options.
My recommendation is to use the kvm cpu types if you really are launched accelerated
guests all the time. If you want to mix and match, use qemu64 (and use the --enable-kvm
flag to get the optional acceleration).
Also note that we can beef up the capabilities as required, like so:
-cpu qemu64,+x2apic
Which means you can add any instruction or capability that -cpu host used to offer, but
do it in a safer way.
Thanks Bruce, much appreciated. I've sent out a patch for review which fixes the problem for me locally. Resolved in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b8819b02dc4ff29d678cc55887dfe6c2d109a67d *** Bug 4569 has been marked as a duplicate of this bug. *** Thanks, works now. Marked as Verified. |