Re: [Xen-devel] [PATCH v5 1/4] x86/HVM: cancel emulation when register state got altered

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.03.2020 14:16, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Jan
>> Beulich
>> Sent: 03 March 2020 10:17
>> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné
>> <roger.pau@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Paul Durrant <paul@xxxxxxx>
>> Subject: [EXTERNAL][Xen-devel] [PATCH v5 1/4] x86/HVM: cancel emulation
>> when register state got altered
>>
>> Re-execution (after having received data from a device model) relies on
>> the same register state still being in place as it was when the request
>> was first sent to the device model. Therefore vCPU state changes
>> effected by remote sources need to result in no attempt of re-execution.
>> Instead the returned data is to simply be ignored.
>>
>> Note that any such asynchronous state changes happen with the vCPU at
>> least paused (potentially down and/or not marked ->is_initialised), so
>> there's no issue with fiddling with register state behind the actively
>> running emulator's back. Hence the new function doesn't need to
>> synchronize with the core emulation logic.
>>
>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Need we be concerned with any page-split I/O here? That may manifest as
> two separate emulations and AFAICT it would be possible for only the
> second part to be aborted by this change.

I'm not sure whether e.g. INIT is recognized only on insn boundaries.
I.e. this may not be that different from real hardware behavior. _If_
we were to take care of this, how would you envision undoing the
first part of such an access, most notably when the access has side
effects?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel