* [Xen-devel] [PATCH] x86emul: correct far branch handling for 64-bit mode
@ 2019-12-13 12:54 Jan Beulich
2019-12-13 13:01 ` Andrew Cooper
0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2019-12-13 12:54 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monné
AMD and friends explicitly specify that 64-bit operands aren't possible
for these insns. Nevertheless REX.W isn't fully ignored: It still
cancels a possible operand size override (0x66). Intel otoh explicitly
provides for 64-bit operands on the respective insn page of the SDM.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2519,9 +2519,16 @@ x86_decode_onebyte(
case 6: /* push */
if ( mode_64bit() && op_bytes == 4 )
op_bytes = 8;
- /* fall through */
+ state->desc = DstNone | SrcMem | Mov;
+ break;
+
case 3: /* call (far, absolute indirect) */
case 5: /* jmp (far, absolute indirect) */
+ /* REX.W ignored on a vendor-dependent basis. */
+ if ( op_bytes == 8 &&
+ (ctxt->cpuid->x86_vendor &
+ (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
+ op_bytes = 4;
state->desc = DstNone | SrcMem | Mov;
break;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xen-devel] [PATCH] x86emul: correct far branch handling for 64-bit mode
2019-12-13 12:54 [Xen-devel] [PATCH] x86emul: correct far branch handling for 64-bit mode Jan Beulich
@ 2019-12-13 13:01 ` Andrew Cooper
2019-12-13 13:07 ` Jan Beulich
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cooper @ 2019-12-13 13:01 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Wei Liu, Roger Pau Monné
On 13/12/2019 12:54, Jan Beulich wrote:
> AMD and friends explicitly specify that 64-bit operands aren't possible
> for these insns. Nevertheless REX.W isn't fully ignored: It still
> cancels a possible operand size override (0x66). Intel otoh explicitly
> provides for 64-bit operands on the respective insn page of the SDM.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2519,9 +2519,16 @@ x86_decode_onebyte(
> case 6: /* push */
> if ( mode_64bit() && op_bytes == 4 )
> op_bytes = 8;
> - /* fall through */
> + state->desc = DstNone | SrcMem | Mov;
> + break;
> +
> case 3: /* call (far, absolute indirect) */
> case 5: /* jmp (far, absolute indirect) */
> + /* REX.W ignored on a vendor-dependent basis. */
> + if ( op_bytes == 8 &&
> + (ctxt->cpuid->x86_vendor &
> + (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
I'm wondering whether in general we want some amd_like() and
intel_like() predicates. It is how almost all of the boundaries end up
falling.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xen-devel] [PATCH] x86emul: correct far branch handling for 64-bit mode
2019-12-13 13:01 ` Andrew Cooper
@ 2019-12-13 13:07 ` Jan Beulich
0 siblings, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2019-12-13 13:07 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu, Roger Pau Monné
On 13.12.2019 14:01, Andrew Cooper wrote:
> On 13/12/2019 12:54, Jan Beulich wrote:
>> AMD and friends explicitly specify that 64-bit operands aren't possible
>> for these insns. Nevertheless REX.W isn't fully ignored: It still
>> cancels a possible operand size override (0x66). Intel otoh explicitly
>> provides for 64-bit operands on the respective insn page of the SDM.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Thanks.
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2519,9 +2519,16 @@ x86_decode_onebyte(
>> case 6: /* push */
>> if ( mode_64bit() && op_bytes == 4 )
>> op_bytes = 8;
>> - /* fall through */
>> + state->desc = DstNone | SrcMem | Mov;
>> + break;
>> +
>> case 3: /* call (far, absolute indirect) */
>> case 5: /* jmp (far, absolute indirect) */
>> + /* REX.W ignored on a vendor-dependent basis. */
>> + if ( op_bytes == 8 &&
>> + (ctxt->cpuid->x86_vendor &
>> + (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
>
> I'm wondering whether in general we want some amd_like() and
> intel_like() predicates. It is how almost all of the boundaries end up
> falling.
I've been wondering the same, but didn't do so yet because while
for Hygon we can be pretty sure it's AMD-like, I'm not sure how
far we could go with covering other than Intel as Intel-like.
But yes, perhaps we could start with just amd_like() (I don't
particularly like this name, but I also can't think of anything
I would like better).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-13 21:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-13 12:54 [Xen-devel] [PATCH] x86emul: correct far branch handling for 64-bit mode Jan Beulich
2019-12-13 13:01 ` Andrew Cooper
2019-12-13 13:07 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.