Re: Xen 4.3 development update RC2 imminent

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 21/05/13 15:55, Jan Beulich wrote:
>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 21/05/13 15:06, Anthony PERARD wrote:
>>> But then, once this applied, qxl is still not able to start. Xorg crash
>>> (in the guest), and here is why:
>>>
>>> (XEN) emulate.c:88:d18 bad mmio size 16
>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f
>>> 19 41 83 e8 403
>>> (XEN) emulate.c:88:d18 bad mmio size 16
>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f
>>> 19 41 83 e8 403
>> Disassembly of section .data:
>>
>> 0000000000000000 <.data>:
>>    0:    f3 0f 6f 19              movdqu (%rcx),%xmm3
>>
>> Xen does not support emulating SSE instructions.  We have sporadically
>> seen similar errors from Windows guests.  The best guess I have managed
>> to get so far is that %rcx is a pointer to something which Xen thinks is
>> an MMIO page.
>>
>> In this case, it looks like X is copying from MMIO into an xmm register,
>> scraping the framebuffer perhaps?  In the windows failure, it was the
>> pagescrub trying to zero ram, which clearly indicated something wonky in
>> the combined idea of the memory map.
>>
>> If Spice is doing something valid and sensible, then Xen will likely
>> need extending to be able to emulate SSE instructions.
> The emulator in the hypervisor can handle simple SSE instructions
> like the above quite well. It's not immediately clear to me why
> hvmemul_do_io() would need to limit the size to no more than a
> long's width. Perhaps the data passing to the device model may
> need adjustment to accommodate wider entities...
>
> Jan
>

Ah yes - my mistake.  When I traced the code for my previous problem, it
was actually a movntps instruction, which was specifically not emulated
by Xen.  I incorrectly assumed that the same would apply to movqdu.

~Andrew