On 03.03.2020 15:44, Durrant, Paul wrote: >> -----Original Message----- >> From: Jan Beulich <jbeul...@suse.com> >> Sent: 03 March 2020 14:34 >> To: Durrant, Paul <pdurr...@amazon.co.uk> >> Cc: xen-devel@lists.xenproject.org; Andrew Cooper >> <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; Wei >> Liu <w...@xen.org>; Paul Durrant <p...@xen.org> >> 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 <jbeul...@suse.com> >>>> Sent: 03 March 2020 14:21 >>>> To: Durrant, Paul <pdurr...@amazon.co.uk> >>>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper >>>> <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; >> Wei >>>> Liu <w...@xen.org>; Paul Durrant <p...@xen.org> >>>> 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-boun...@lists.xenproject.org> On Behalf Of >>>> Jan >>>>>> Beulich >>>>>> Sent: 03 March 2020 10:17 >>>>>> To: xen-devel@lists.xenproject.org >>>>>> Cc: Andrew Cooper <andrew.coop...@citrix.com>; Roger Pau Monné >>>>>> <roger....@citrix.com>; Wei Liu <w...@xen.org>; Paul Durrant >>>> <p...@xen.org> >>>>>> 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.coop...@citrix.com> >>>>>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >>>>> >>>>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
