Re: [KVM paravirt issue?] Re: vsyscall=emulate regression

[Avi Kivity <avi@redhat.com>]

On 02/16/2012 07:35 PM, Andy Lutomirski wrote:
> >
> > so it seems like kvm doesn't set PF_INSTR?
>
> Yes, this is on purpose, and you're almost certainly right (and I feel
> dumb for not figuring this out immediately).  The error message is:
>
> segfault at ffffffffff600400 ip ffffffffff600400 sp 00007fff103d72f8 error 5
>
> which is garbage.  The instruction at 0xffffffffff600400 can't fetch
> itself as data and fault on the data access (at least not in 64-bit
> mode, as far as I can think of, without evil messing with the TLBs).
>
> So... what do we do about this?  This (whitespace-damaged, untested)
> patch will probably work around it well enough to boot the system:
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 9d74824..52b9522 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -741,8 +741,11 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long
>                  * Instruction fetch faults in the vsyscall page might need
>                  * emulation.
>                  */
> -               if (unlikely((error_code & PF_INSTR) &&
> +               if (unlikely(address == regs->ip && !(error_code & PF_WRITE) &&
>                              ((address & ~0xfff) == VSYSCALL_START))) {
> +                       WARN_ONCE(!(error_code & PF_INSTR),
> +                                 "Fixing up bogus vsyscall read fault -- "
> +                                 "your hypervisor is buggy.");
>                         if (emulate_vsyscall(regs, address))
>                                 return;
>                 }
>
> Before we patch the guest like this, though, it would be nice to know
> what hosts are affected.  If it's just one version of RHEL6, maybe it
> makes sense to fix the hypervisor and either leave the guest alone or
> just add a warning saying to fix your hypervisor, like:
>
> WARN_ONCE(address == regs->ip && !(error_code & (PF_INSTR | PF_WRITE))
> && user_64bit_mode(regs), "Fishy page fault -- you might need to fix
> your hypervisor");
>
> near some exit path in the page fault handler.  The 64-bit check is
> because (I think) 32-bit code can mess with regs->ip using a cs offset
> in the LDT and trigger the warning at will.
>

We'll just fix all affected hypervisor versions.  No need to uglify the
guest for a clear kvm bug.

-- 
error compiling committee.c: too many arguments to function