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:57
> 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][PATCH v5 1/4] x86/HVM: cancel emulation when register 
> state got altered
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 03.03.2020 15:44, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >> Sent: 03 March 2020 14:34
> >> 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][PATCH v5 1/4] x86/HVM: cancel emulation when
> >> register state got altered
> >>
> >> CAUTION: This email originated from outside of the organization. Do not
> >> click links or open attachments unless you can confirm the sender and know
> >> the content is safe.
> >>
> >>
> >>
> >> On 03.03.2020 15:25, Durrant, Paul wrote:
> >>>> -----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.
> >>
> >> Hmm, at the first glance this looks ugly/fragile to arrange for. I'm
> >> having a hard time thinking of a rough sketch of how such could be
> >> made work, in particular without blocking the vcpu_pause() itself
> >> for too long.
> >>
> >
> > If the vcpu is at the mercy of an external emulator it could take a
> > while. I can't really think of a way to avoid that though. Maybe
> > pausing at a non-architectural boundary is ok here though.
> 
> Well, at the very least I'd call it good enough until we can think
> of a sensible way to deal with this.
> 

Ok. You can have my R-b on this one then.

  Paul

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