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