Re: [PATCH v5 1/5] x86/asm: Carve out a generic movdir64b() helper for general usage

[Michael Matz]

Hello,

even though we hashed it out downthread, let me make some additional 
remarks:

On Thu, 24 Sep 2020, Borislav Petkov wrote:

> > 	/* MOVDIR64B [rdx], rax */

This comment is confusing as it uses Intel syntax for the operand forms, 
but AT&T order (dest last).

> 	volatile struct { char _[64]; } *__dst = dst;
> 
> 	...
> 
> 	: "=m" (__dst)

This and the other occurences in this thread up to now always miss that 
the 'm' constraints want the object itself, not the address of the object.  
So you want '"m" (*__src)', same for dst, and so on.

> Micha, the instruction is:
> 
> MOVDIR64B %(rdx), rax
> 
> "Move 64-bytes as direct-store with guaranteed 64-byte write atomicity
> from the source memory operand address to destination memory address
> specified as offset to ES segment in the register operand."

It's unfortunate that the introduction of this mnemonic into binutils 
did it wrong already, but what the instruction should really read like in 
AT&T mode is:

  movdir64b (%rdx), (%rax)
or even
  movdir64b (%rdx), es:(%rax)

because both are memory operands really (even though the destination can 
only be encoded with a direct register, as these are the constraints of 
x86 insn encodings).  It's comparable to movs, which, also having two 
memory operands is written:

  movsb  %ds:(%rsi),%es:(%rdi)


Ciao,
Michael.