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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 01.08.14 at 21:15, <tim@xen.org> wrote:
> At 15:27 +0100 on 01 Aug (1406903251), Jan Beulich wrote:
>> Btw., while I expect the second shortcut to also help a little (I was
>> only able to functionality test it, as I don't have a big enough system
>> around to meaningfully test that big a guest), while going through
>> all the pCPU-s' stack trace snapshots it occurred to me that for
>> hvm_hap_nested_page_fault()-induced MMIO emulation it is in many
>> cases quite pointless to "manually" do the VA->GPA translation, since
>> the handler already gets passed the offending GPA. Of course some
>> care would need to be taken to e.g. not use this on instructions
>> having more than one memory operand, or where the memory
>> operand crosses page boundaries, but all the information needed
>> for this would be available after decoding the instruction, i.e. well
>> in time before evaluating instruction operands. Am I overlooking
>> any other aspect making such an optimization unsafe?
> 
> 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. Furthermore there are sanity
checks we can do, like validating at least the offset into the page
(but yes, that would make eventual problems resulting from this
optimization even more difficult to reproduce/locate, albeit
failures of any such sanity check should probably have a
[conditional] log message associated, so one can spot that we
_would_ have done the optimization otherwise).

Jan