>>> On 10.12.15 at 21:03, <andrew.coop...@citrix.com> wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -570,8 +570,10 @@ do{ asm volatile (
> \
> /* Fetch next part of the instruction being emulated. */
> #define insn_fetch_bytes(_size) \
> ({ unsigned long _x = 0, _eip = _regs.eip; \
> - if ( !mode_64bit() ) _eip = (uint32_t)_eip; /* ignore upper dword */ \
> - _regs.eip += (_size); /* real hardware doesn't truncate */ \
> + _regs.eip += (_size); \
> + if ( !mode_64bit() ) { /* Truncate eip to def_ad_bytes (2 or 4). */ \
> + _eip &= ~((1UL << (def_ad_bytes * 8)) - 1); \
Okay, what we use for actual fetching gets truncated. I'm fine
with that.
> + _regs.eip &= ~((1UL << (def_ad_bytes * 8)) - 1); }; \
But I don't think it's correct to truncate what eventually gets
written back. If we're in doubt what real hardware does, and if
the manuals are of no help, perhaps we should ask the hardware
folks?
AMD? Intel? Please clarify.
Furthermore, doesn't this make the wrapping-inside-an-insn
situation worse (i.e. what looks broken for 32- and 64-bit modes
now gets broken also for 16-bit mode)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
