On Tue, Feb 28, 2023 at 6:43 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
>
>
> On 28 February 2023 22:48:42 GMT, Brian Gerst <brgerst@xxxxxxxxx> wrote:
> >On Tue, Feb 28, 2023 at 5:41 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> >>
> >> On Tue, 2023-02-28 at 21:57 +0000, David Woodhouse wrote:
> >> >
> >> > ----------------
> >> > IN:
> >> > 0xffffffffa20000b2: 48 31 d2 xorq %rdx, %rdx
> >> > 0xffffffffa20000b5: 48 8b 82 c0 74 d5 a3 movq -0x5c2a8b40(%rdx), %rax
> >> > 0xffffffffa20000bc: 48 8b a0 58 14 00 00 movq 0x1458(%rax), %rsp
> >> > 0xffffffffa20000c3: 48 83 ec 10 subq $0x10, %rsp
> >> > 0xffffffffa20000c7: 66 c7 04 24 7f 00 movw $0x7f, (%rsp)
> >> > 0xffffffffa20000cd: 48 8d 82 00 10 81 a3 leaq -0x5c7ef000(%rdx), %rax
> >> > 0xffffffffa20000d4: 48 89 44 24 02 movq %rax, 2(%rsp)
> >> > 0xffffffffa20000d9: 0f 01 14 24 lgdtq (%rsp)
> >> > 0xffffffffa20000dd: 48 83 c4 10 addq $0x10, %rsp
> >> > 0xffffffffa20000e1: 31 c0 xorl %eax, %eax
> >> > 0xffffffffa20000e3: 8e d8 movl %eax, %ds
> >> >
> >> > I cannot work out where the value -0x5c7ef000 comes from, but it
> >> > doesn't seem to be the 0xb000 you claimed, and my brain is hurting
> >> > again...
> >>
> >> Turning off CONFIG_RANDOMIZE_BASE (or just looking at the vmlinux
> >> disassembly instead as Brian did) helps to resolve that FWIW.
> >>
> >> I've changed it to zero all of %rdx and pushed it back to the v12bis
> >> branch.
> >
> >xorl %edx, %edx is preferred, as a 32-bit operation zero-extends to
> >the full 64-bit register. Using xorq to clear any of the lower 8
> >registers adds an unnecessary REX prefix. Just one of many quirks of
> >the x86 instruction set...
>
> Ewww. Couldn't the assembler choose to omit the REX prefix then? It does more tricksy things than that already.
>
> I almost prefer having the prefix but (in the morning) if you prefer I can put it back as it was with a comment about the zero-extension.
commit a7bea8308933aaeea76dad7d42a6e51000417626
Author: Jan Beulich <JBeulich@xxxxxxxx>
Date: Mon Jul 2 04:31:54 2018 -0600
x86/asm/64: Use 32-bit XOR to zero registers
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms. Zeroing
idioms don't require execution bandwidth, as they're being taken care
of in the frontend (through register renaming). Use 32-bit XORs instead.
Not that speed is important here, but it's good to be consistent
across the whole kernel. Someone will eventually come by and fix it
up anyways, as there have been a few of these patches already in the
git history.
--
Brian Gerst
