Re: [Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/09/16 15:28, Jan Beulich wrote:
>>>> On 08.09.16 at 16:11, <andrew.cooper3@xxxxxxxxxx> wrote:
>> The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
>> rdtsc, but isn't really an instruction prefix.  It behaves as a break-out 
>> into
>> Xen, with the purpose of emulating the next instruction in the current state.
>>
>> It is important to be able to test legal situations which occur in real
>> hardware, including instruction which cross certain boundaries, and
>> instructions starting at 0.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> While you did mostly convince me at that time, I've got some more
> concerns here: What if the instruction to be emulated causes a
> fault that then needs to be propagated to and handled by the
> guest, before it can be restarted? Such a fault would be raised
> with rIP pointing past the forced emulation prefix, and hence the
> restarted instruction then wouldn't get emulated.

The current behaviour is to report a fault at the start of the real
instruction.

Furthermore, this is the useful behaviour for it to have.  If a guest is
explicitly probing the Xen x86 emulator with FEP, it can take
responsibility of rewinding %rip by 5 if it needs to replay.

Having said that, I haven't yet encountered a case where replaying a
faulting instruction in a test is useful.  All tests thusfar check that
in specific situations, faults occur architecturally whether run on real
hardware, or via the xen emulator.

> Along those line, if you don't want to treat this as an instruction
> prefix, there ought to be two #DB due to instruction breakpoint
> match (if set for both places, of course), yet that's impossible to
> implement together with the desire to emulate the insn.

True, but I don't see this is a problem.

The *only* code using FEP is test code deliberately trying to elicit
behaviour from the Xen emulator and check that it matches real
hardware.  It is perfectly fine for test code to know its special when
it is using a special backdoor to perform said tests.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel