Re: [PATCH] x86/HVM: extend LAPIC shortcuts around P2M lookups

[Tim Deegan <tim@xen.org>]

At 09:34 +0100 on 06 Aug (1407314042), Jan Beulich wrote:
> >>> On 05.08.14 at 21:53, <tim@xen.org> wrote:
> > At 08:12 +0100 on 04 Aug (1407136337), Jan Beulich wrote:
> >> >>> On 01.08.14 at 21:15, <tim@xen.org> wrote:
> >> > If Xen does its own instruction fetch and decode, then we have to be
> >> > careful about reusing any state from the original exit because of
> >> > self-modifying code.  (And yes, that is a serious concern -- I once
> >> > spent months trying to debug occasional memory corruption in the
> >> > self-modifying license-enforcement code on a system stress test
> >> > utility.)
> >> > 
> >> > So it would be OK to reuse the GPA from the exit if we could verify
> >> > that the GVA we see is the same as the original fault (since there can't
> >> > have been a TLB flush).  But IIRC the exit doesn't tell us the
> >> > original GVA. :(
> >> 
> >> I don't think it needs to be as strict as this: For one, I wouldn't
> >> intend to use the known GPA for instruction fetches at all. And
> >> then I think if the instruction got modified between the exit and us
> >> doing the emulation, using the known GPA with the wrong
> >> instruction is as good or as bad as emulating an instruction that
> >> didn't originally cause the exit.
> > 
> > Not at all -- as I said, in the shadow code we did see the case where
> > we emulated a different instruction, and we do our best to handle it.
> > And at least there we have a clean failure mode: if we can't emulate
> > we crash.
> > 
> > Using the wrong GPA will silently corrupt memory and carry on, which
> > is about the worst failure mode a VMM can have (esp. if skipping the
> > GVA->GPA walk could allow a guest process to write to a read-only
> > mapping).  
> 
> Indeed, thinking about it again I agree. Fortunately it looks like we're
> having ways to accelerate this nevertheless: On EPT, the handler
> gets the linear address, we just need to make use of it. I just finished
> drafting a respective patch - hopefully I'll get to trying it out later
> today.
> 
> > I'd be extremely uncomfortable with anything like tis unless there's a
> > way to get either the ifetch buffer or a partial decode out of the CPU
> > (which IIRC can't be done on x86 though it can on ARM).
> 
> On NPT we also get the instruction bytes on nested page faults, at
> least on newer hardware. So maybe we could cook up something
> along the lines you indicate by flagging that the instruction bytes
> came from hardware.

Oh good -- yes, both of those approaches sound very encouraging.

Tim.