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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
