Re: Possible problem emulating movntq, movss

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 08/06/2014 03:50 PM, Jan Beulich wrote:
>>>> On 06.08.14 at 14:16, <JBeulich@suse.com> wrote:
>>>>> On 06.08.14 at 12:47, <vlutas@bitdefender.com> wrote:
>>> On 8/6/2014 12:54 PM, Jan Beulich wrote:
>>>>>>> On 06.08.14 at 10:57, <rcojocaru@bitdefender.com> wrote:
>>>>> We found that our HVM guests froze when trying to emulate movntq
>>>>> instructions. The solution seems to be to replace "goto done;" with
>>>>> "break;" at line 4191 (when handling "case 0x7f:") in
>>>>> xen/arch/x86/x86_emulate/x86_emulate.c. Otherwise the writeback part
>>>>> doesn't happen.
>>>>>
>>>>> If you're happy with the fix I can prepare a patch, otherwise please let
>>>>> me know if we're missing something.
>>>> No, that doesn't look right: There's nothing left to be written back at
>>>> that point (registers get updated with the instruction executed via the
>>>> on-stack stub, and memory gets written with immediately preceding
>>>> ops->write(). So without you being more specific about _what_ you
>>>> see going wrong I don't think I can give further advice.
>>> Except for maybe the instruction pointer? That doesn't seem to be updated
>>> anywhereexcept during the write-back phase (or maybe I'm missing the spot).
>>> The problem is that the guest gets stuck with the instruction pointer
>>> pointing to the sameinstruction (in our particular case it is
>>> "MOVDQU xmm0, xmmword ptr [rdx + rcx - 0x10]"),entering in an infinite
>>> loop (EPT violation - emulate), since the IP doesn't seem to be updated.
>>
>> Now that is indeed a problem, but not solved by simply replacing
>> the "goto done" with "break". I'll look into getting you a proper fix.
> 
> Mind giving this one (lightly tested only) a try?

We've tested this with both a modified version of test_x86_emulator.c
(small patch to follow) and our HVM guest, and everything seems to be
working.


Thanks,
Razvan Cojocaru