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

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 03 March 2020 14:21
> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>; Wei
> Liu <wl@xxxxxxx>; Paul Durrant <paul@xxxxxxx>
> Subject: RE: [EXTERNAL][Xen-devel] [PATCH v5 1/4] x86/HVM: cancel
> emulation when register state got altered
> 
> 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?

I wasn't thinking of undoing... I was more thinking that vcpu_pause() ought to 
defer until an in-progress emulation has fully completed.

  Paul

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