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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
