Messages in this thread | | | Date | Thu, 16 Feb 2012 19:14:03 +0200 | From | Avi Kivity <> | Subject | Re: [KVM paravirt issue?] Re: vsyscall=emulate regression |
| |
On 02/16/2012 06:45 PM, Andy Lutomirski wrote: > > > >> So I could have messed up, or there could be a subtle > >> bug somewhere. Any ideas? > > > > What's the code trying to do? Execute an instruction from an > > non-executable page, trap the #PF, and emulate? And what are the > > symptoms? wrong error code for the #PF? That could easily be a kvm bug. > > > > The symptom is that some kind of access to a page that's supposed to > be readable, NX is reporting error 5. I'm not quite sure what kind of > access is causing that.
Might it be a fetch access, with kvm forgetting to set bit 4 correctly?
> > > > Can you point me at the code in question? > > The setup code is in arch/x86/kernel/vsyscall_64.c in map_vsyscall. > The bad access is to the vsyscall page.
The bad access is on purpose, yes?
From fault.c:
#ifdef CONFIG_X86_64 /* * Instruction fetch faults in the vsyscall page might need * emulation. */ if (unlikely((error_code & PF_INSTR) && ((address & ~0xfff) == VSYSCALL_START))) { if (emulate_vsyscall(regs, address)) return; } #endif
so it seems like kvm doesn't set PF_INSTR?
I thought we unit tested that, but maybe not this exact scenario.
-- error compiling committee.c: too many arguments to function
| |