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. There are corner cases which we can't possibly reasonably cope with. e.g. It is model specific as to whether UD0 takes a ModRM byte or not, and I'll note that the latest revision (3.31) of APM Vol2 clarifies in Table 8-8: "This reflects the relative priority for faults encountered when fetching the first byte of an instruction. In the fetching and decoding of subsequent bytes of an instruction, if those bytes span the segment limit or cross into a non-executable or not-present page, the fetch will result in a #GP(0) fault or #PF as appropriate, preventing those bytes from being accessed. However, if the instruction can be determined to be invalid based just on the bytes preceding that boundary, a #UD fault may take priority. This behavior is model-dependent." so we have no hope of getting model-accurate fault behaviour. > While touching this code I also noticed that #UD outside of protected > mode gets raised for ARPL only after having read the memory operand - > correct this atthe same time by moving up the respective construct. at the. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
