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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan

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