>>> On 28.03.17 at 12:50, <rcojoc...@bitdefender.com> wrote:
> On 03/28/2017 01:47 PM, Jan Beulich wrote:
>>>>> On 28.03.17 at 12:27, <rcojoc...@bitdefender.com> wrote:
>>> On 03/28/2017 01:03 PM, Jan Beulich wrote:
>>>>>>> On 28.03.17 at 11:14, <rcojoc...@bitdefender.com> wrote:
>>>>> I'm not sure that the RETRY model is what the guest OS expects. AFAIK, a
>>>>> failed CMPXCHG should happen just once, with the proper registers and ZF
>>>>> set. The guest surely expects neither that the instruction resume until
>>>>> it succeeds, nor that some hidden loop goes on for an undeterminate
>>>>> ammount of time until a CMPXCHG succeeds.
>>>>
>>>> The guest doesn't observe the CMPXCHG failing - RETRY leads to
>>>> the instruction being restarted instead of completed.
>>>
>>> Indeed, but it works differently with hvm_emulate_one_vm_event() where
>>> RETRY currently would have the instruction be re-executed (properly
>>> re-executed, not just re-emulated) by the guest.
>>
>> Right - see my other reply to Andrew: The function likely would
>> need to tell apart guest CMPXCHG uses from us using the insn to
>> carry out the write by some other one. That may involve
>> adjustments to the memory write logic in x86_emulate() itself, as
>> the late failure of the comparison then would also need to be
>> communicated back (via ZF clear) to the guest.
>
> Exactly, it would require quite some reworking of x86_emulate().
I don't think so, no. It would merely require a special case step
following ->cmpxchg() to deal with it being CMPXCHG we're
emulating. Plus matching code in CMPXCHG{8,16}B emulation.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
