From: Uros Bizjak <[email protected]> > > Use MOVL when reading segment registers to avoid 0x66 operand-size > override insn prefix. The segment value is always 16-bit and gets > zero-extended to the full 32-bit size. > > Signed-off-by: Uros Bizjak <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: Borislav Petkov <[email protected]> > Cc: Dave Hansen <[email protected]> > Cc: "H. Peter Anvin" <[email protected]> > --- > arch/x86/include/asm/segment.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h > index f59ae7186940..9f5be2bbd291 100644 > --- a/arch/x86/include/asm/segment.h > +++ b/arch/x86/include/asm/segment.h > @@ -348,7 +348,7 @@ static inline void __loadsegment_fs(unsigned short value) > * Save a segment register away: > */ > #define savesegment(seg, value) \ > - asm("mov %%" #seg ",%0":"=r" (value) : : "memory") > + asm("movl %%" #seg ",%k0" : "=r" (value) : : "memory") > > #endif /* !__ASSEMBLER__ */ > #endif /* __KERNEL__ */ > -- > 2.51.1 >
I've built a linux-next20251119 kernel plus the three patches in this series, and tested it in an SEV-SNP VM in the Azure public cloud. The VM is a Standard DC16ads v5 (16 vcpus, 64 GiB memory) running Ubuntu 20.04. It boots and does basic smoke tests with no issues. So, for all three patches, Tested-by: Michael Kelley <[email protected]> I do have a comment on the commit message for Patch 3 (I would have replied there, but for unknown reasons the third patch didn't show up in my LKML feed). The commit message says "VMMCALL ... may be inserted before the frame pointer". This text was somewhat ambiguous to me. I initially read it as "the compiler might insert VMCALL before the frame pointer is set up". But I think you meant "it's OK to allow the compiler to insert the VMMCALL before the frame point is set up". Maybe the intended meaning is obvious to experts in this area, but I'm new enough that it was confusing to me. ;-) To avoid any future confusion, I'd suggest this wording, which is explicit about why this patch is appropriate: Unlike the CALL instruction, VMMCALL does not push to the stack, so it's OK to allow the compiler to insert it before the frame pointer gets set up by the containing function. ASM_CALL_CONSTRAINT is for CALLs that must be after the frame pointer is set up, so it is over-constraining here and can be removed. FWIW, removing the ASM_CALL_CONSTRAINT does not change the generated code for hv_snp_hypercall(). Michael
