All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.