Hi, kvm people- Here's a strange failure. It could be a bug in something RHEL6-specific, but it could be a generic issue that only triggers with a paravirt guest with old userspace on a non-ept host. There was a bug like this on Xen, and I'm wondering something's wrong on kvm as well.
For background, a change in 3.1 (IIRC) means that, when vsyscall=emulate or vsyscall=none, the vsyscall page in the fixmap is NX. It seems like Amit's machine is marking the physical PTE present but unreadable. So I could have messed up, or there could be a subtle bug somewhere. Any ideas? I'll try to reproduce on a non-ept host later on, but that will involve finding one. On Wed, Feb 15, 2012 at 3:01 AM, Amit Shah <amit.s...@redhat.com> wrote: > On (Tue) 14 Feb 2012 [08:26:22], Andy Lutomirski wrote: >> On Tue, Feb 14, 2012 at 4:22 AM, Amit Shah <amit.s...@redhat.com> wrote: >> Can you try booting the initramfs here: >> http://web.mit.edu/luto/www/linux/vsyscall_initramfs.img >> with your kernel image (i.e. qemu-kvm -kernel <whatever> -initrd >> vsyscall_initramfs.img -whatever_else) and seeing what happens? It >> works for me. > > This too results in a similar error. Can you post the exact error? I'm interested in how far it gets before it fails. > I didn't try a modern distro, but looks like this is enough evidence > for now to check the kvm emulator code. I tried the same guests on a > newer kernel (Fedora 16's 3.2), and things worked fine except for > vsyscall=none, panic message below. vsyscall=none isn't supposed to work unless you're running a very modern distro *and* you have no legacy static binaries *and* you aren't using anything written in Go (sigh). It will probably either never become the default or will take 5-10 years. > model name : Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm > constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow vnmi > flexpriority Hmm. You don't have ept. If your guest kernel supports paravirt, then you might use the hypercall interface instead of programming the fixmap directly. > > This is what I get with vsyscall=none, where emulate and native work > fine on the 3.2 kernel on different host hardware, the guest stays the > same: > > > [ 2.874661] debug: unmapping init memory ffffffff8167f000..ffffffff818dc000 > [ 2.876778] Write protecting the kernel read-only data: 6144k > [ 2.879111] debug: unmapping init memory ffff880001318000..ffff880001400000 > [ 2.881242] debug: unmapping init memory ffff8800015a0000..ffff880001600000 > [ 2.884637] init[1] vsyscall attempted with vsyscall=none > ip:ffffffffff600400 cs:33 sp:7fff2f48fe18 ax:7fff2f48fe50 si:7fff2f48ff08 di:0 This like (vsyscall attempted) means that the emulation worked correctly. Your other traces didn't have it or anything like it, which mostly rules out do_emulate_vsyscall issues. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
