[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] SSE instruction emulation issues



You can put the MMIO emulation failed output message in the email like what I 
did, that will help to cook a patch for instruction emulator. Only gdb log is 
not enough as xen-developer has to know the exact opcode. I also found that not 
all forms of one SSE instruction was supported, for example an instruction may 
support move data from xmm register to mem, or move from xmm register to xmm 
registers, maybe only one form is supported in the instruction emulator. 

Thanks,
Zhi.

-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx] 
Sent: Wednesday, July 15, 2015 9:56 PM
To: Jan Beulich
Cc: Andrew Cooper; Paul Durrant; Wang, Zhi A; xen-devel
Subject: Re: SSE instruction emulation issues

Il 15/07/2015 13:35, Jan Beulich ha scritto:
>>>> On 15.07.15 at 13:13, <fabio.fantoni@xxxxxxx> wrote:
>> Il 10/07/2015 14:16, Jan Beulich ha scritto:
>>>>>> On 10.07.15 at 14:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 09/07/15 20:32, Zhi Wang wrote:
>>>>>       We found that MOVD instruction are used by some windows 
>>>>> driver during developing XenGT, and also we found this one:
>>>>>
>>>>> (XEN) MMIO emulation failed: d7v1 64bit @ 0010:fffff8000294e273 -> 
>>>>> 66 0f e7 00 48 83 c0 10 45 3 b cb 73 f0 45 85 c9
>>>> Disassembly:
>>>>      0:    66 0f e7 00              movntdq %xmm0,(%rax)
>>>>      4:    48 83 c0 10              add    $0x10,%rax
>>>>      8:    45 3b cb                 cmp    %r11d,%r9d
>>>>      b:    73 f0                    jae    0xfffffffffffffffd
>>>>      d:    45 85 c9                 test   %r9d,%r9d
>>>>
>>>> The x86 instruction emulator does appear to have a decode for this 
>>>> instruction.  This failure suggests that the implementation is buggy.
>>>>
>>>> To start with diagnosing, add a test case to 
>>>> tools/tests/x86_emulator/test_x86_emulator.c
>>> Considering that we already test MOVDQU, the emulation of which 
>>> shares code with MOVNTDQ (which only differs in aspects not of 
>>> interest to the emulator) I'm not sure this will turn up anything 
>>> interesting. Perhaps an even easier step would be to simply run the 
>>> emulator test on the machine where the issue is seen? We're playing 
>>> some prefix byte tricks there... Otoh failure to execute the 
>>> constructed instruction would bring down the hypervisor.
>> I also have a problem with mmio as I already reported many times but 
>> I
> And to be honest, I don't see the value in re-stating this every once 
> in a while without providing any new information.
>
>> don't know if it is the same as the one reported by the intel 
>> developer about xengt, I have it in linux hvm domUs with qxl.
> Looks different - their's was about MOVD (which we clearly don't 
> support right now) while yours looks to be about MOVAPS.
>
>> Today with the latest xen update from git staging (with the addiction 
>> of the xengt patch that add support of emulating SSE2 instruction 
>> MOVD) I had a different domU's Xorg backtrace containing also a 
>> "error: Cannot access memory at address":
> Sadly a gdb backtrace is nothing I can see use extract useful 
> information from. Iirc Paul had already asked you to instrument the 
> involved code paths (considering that the x86 insn emulator supports 
> MOVAPS as used by the failing code) to figure out where in the whole 
> involved stack the failure actually originates.
>
> Jan
>

Thanks for your reply, as I wrote the other times I don't know a better debug 
method about particular things like this (x86 instructions
emulation) and I'm asking what I should do.
If you mean to look at the code involved, search the part about the problem, 
think how can go wrong or unexpected, add debug output if needed, try quick 
changes to it ecc... I can do it with simpler software and I did something 
similar with libxl but I don't know how to do the same for code like 
xen/arch/x86/x86_emulate/x86_emulate.c. I already took a look at it but I 
didn't find "MOVAPS" in comments like many others.
If the problem is located in something like libxl where there are instructions 
that I know or that are intuitive I can imagine what the software is supposed 
to do and I can do quick targeted tests or changes, but on thing like x86 
emulation I can't (or at least not before knowing all instructions and 
essential data about it).
Is this what you mean and is that the only way to collect useful data or to 
solve the problem?
If so, I suppose that for any change in xen/arch/x86/x86_emulate and similar I 
can't simply make the change, do a make, make install and test it immediatly 
like libxl/xl but I have to rebuild full xen, install it and reboot dom0, is it 
right?
Can you post a link with a quick reference about x86 emulation and/or 
instruction sets like sse2 which can help me learn what to do or an extensive 
knowledge on the subject is required in this case?
What kind of logging instruction for debug can I use? Are they visible with xl 
dmesg or I must do something different and more specific in this case?

Thanks for any reply and sorry for my bad english.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.