Re: [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG

["Jan Beulich" <JBeulich@suse.com>]

>>> On 31.03.17 at 11:56, <rcojocaru@bitdefender.com> wrote:
> On 03/31/2017 10:34 AM, Jan Beulich wrote:
>>>>> On 31.03.17 at 08:17, <rcojocaru@bitdefender.com> wrote:
>>> On 03/30/2017 06:47 PM, Jan Beulich wrote:
>>>>> Speaking of emulated MMIO, I've got this when the guest was crashing
>>>>> immediately (pre RETRY loop):
>>>>>
>>>>>  MMIO emulation failed: d3v8 32bit @ 0008:82679f3c -> f0 0f ba 30 00 72
>>>>> 07 8b cb e8 da 4b ff ff 8b 45
>>>>
>>>> That's a BTR, which we should be emulating fine. More information
>>>> would need to be collected to have a chance to understand what
>>>> might be going one (first of all the virtual and physical memory
>>>> address this was trying to act on).
>>>
>>> Right, the BTR part should be fine, but I think the LOCK part is what's
>>> causing the issue. I've done a few more test runs to see what return
>>> RETRY (dumping the instruction with an "(r)" prefix to distinguish from
>>> the UNHANDLEABLE dump), and a couple of instructions return RETRY (BTR
>>> and XADD, both LOCK-prefixed, which means they now involve CMPXCHG
>>> handler, which presumably now fails - possibly simply because it's
>>> always LOCKed in my patch):
>> 
>> Well, all of that looks to be expected behavior. I'm afraid I don't see
>> how this information helps understanding the MMIO emulation failure
>> above.
> 
> I've managed to obtain this log of emulation errors:
> https://pastebin.com/Esy1SkHx 
> 
> The "virtual address" lines that are not followed by any "Mem event"
> line correspond to CMXCHG_FAILED return codes.
> 
> The very last line is a MMIO emulation failed.
> 
> It's probably important that this happens with the model where
> hvm_emulate_one_vm_event() does _not_ re-try the emulation until it
> succeeds. The other model allows me to go further with the guest, but
> eventually I get timeout-related BSODs or the guest becomes unresponsive.

Interesting. You didn't clarify what the printed "offset" values are,
and it doesn't look like these have any correlation with the underlying
(guest) physical address, which we would also want to see. And then
it strikes me as odd that in these last lines

(XEN) Mem event (RETRY) emulation failed: d5v8 32bit @ 0008:826bb861 -> f0 0f ba 30 00 72 07 8b cb e8 da 4b ff ff 8b 45
(XEN) virtual address: 0xffd080f0, offset: 4291854576
(XEN) MMIO emulation failed: d5v8 32bit @ 0008:82655f3c -> f0 0f ba 30 00 72 07 8b cb e8 da 4b ff ff 8b 45

the instruction pointers and virtual addresses are different, but the
code bytes are exactly the same. This doesn't seem very likely, so I
wonder whether there's an issue with us wrongly re-using previously
fetched insn bytes. (Of course I'd be happy to be proven wrong with
this guessing, by you checking the involved binary/ies.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel