Re: [Xen-devel] [PATCH 2/2] x86emul: adjust MOVSXD source operand handling

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.09.2019 21:22, Andrew Cooper wrote:
> On 18/09/2019 07:34, Jan Beulich wrote:
>> On 17.09.2019 19:17, Andrew Cooper wrote:
>>> On 16/09/2019 10:48, Jan Beulich wrote:
>>>> XED commit 1b2fd94425 ("Update MOVSXD to modern behavior") points out
>>>> that as of SDM rev 064 MOVSXD is specified to read only 16 bits from
>>>> memory (or register) when used without REX.W and with operand size
>>>> override. Since the upper 16 bits of the value read won't be used
>>>> anyway in this case, make the emulation uniformly follow this more
>>>> compatible behavior when not emulating an AMD-like CPU, at the risk
>>>> of missing an exception when emulating on/for older hardware (the
>>>> boundary at SandyBridge noted in said commit looks questionable - I've
>>>> observed the "new" behavior also on Westmere).
>>> AMD documents this instruction has always using an 8 or 16bit source
>>> operand.
>> Have you mixed up MOVSX with MOVSXD? Both have separate pages in
>> AMD's doc, but a common page in Intel's.
> 
> I had confused the two, yes.
> 
> I constructed an experiment using 66 6e 08, i.e.
> 
> movslq (%rax),%cx
> 
> according to objdump, and iterating backwards over the boundary to the
> unmapped page at 0.
> 
> On a Rome system:
> 
> (d24) Ptr: 0000000000001000
> (d24)  => c2c2
> (d24) Ptr: 0000000000000fff
> (d24) ******************************
> (d24) PANIC: Unhandled exception at 0008:00000000001047a5
> (d24) Vec 14 #PF[-d-sr-] %cr2 0000000000000fff
> (d24) ******************************
> 
> Which also confirms the description which states that in the case of a
> 16 bit operand, no sign extension occurs.
> 
> I then tried the same test on an Intel Haswell system:
> 
> (d91) Ptr: 0000000000001000
> (d91)  => c2c2
> (d91) Ptr: 0000000000000fff
> (d91) ******************************
> (d91) PANIC: Unhandled exception at 0008:00000000001047a5
> (d91) Vec 14 #PF[-d-sr-] %cr2 0000000000000fff
> (d91) ******************************

But judging from the "Ptr: 0000000000000fff" in the log I take
it you tried to access a byte rather than a word (which would
need an address of 0000000000000ffe to distinguish whether it's
a 2- or 4-byte read that the CPU issues). Trust me, I did try
this out, which is also why I noticed that Mark's claim of
the behavior having changed with SandyBridge is likely wrong.
He has meanwhile confirmed that Merom also already behaved this
way.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel