Re: [Xen-devel] [PATCH v2] x86/EFI: meet further spec requirements for runtime calls

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/11/16 10:32, Jan Beulich wrote:
> So far we didn't guarantee 16-byte alignment of the stack: While (so
> far) we don't tell the compiler to use smaller alignment, we also don't
> guarantee 16-byte alignment when establishing stack pointers for new
> vCPU-s. Runtime service functions using SSE instructions may end with
> #GP(0) without that.
>
> Note that making use of -mpreferred-stack-boundary=3, as mentioned in
> the comment, wouldn't help to reduce the needed alignment: The compiler
> would then be free to align the stack of the function with the aligned
> object, but would be permitted to place an odd number of 8-byte objects
> there, resulting in the callee to still run on an unaligned stack.
>
> (The only working alternative to the approach chosen here would be to
> use -mincoming-stack-boundary=3, but that would affect all functions in
> runtime.c, not just the ones actually making runtime services calls.
> And it would still require the manual alignment logic here to be used
> with gcc 5.2 and earlier - not permitting that command line option -,
> just that then the alignment amount would become conditional.)
>
> Hence enforce the needed alignment by making efi_rs_enter() return a
> suitably aligned structure, which the caller then necessarily has to
> store in a suitably aligned local variable, the address of which then
> gets passed to efi_rs_leave(). Also (to limit exposure) move the
> function declarations to where they belong: They're local to runtime.c,
> and shared only with compat.c (by the latter including the former).

Why does this guarantee alignment?  What prevents the compiler from
reordering the items in its stack layout?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel