On 02.10.2024 12:30, Andrew Cooper wrote: > No functional change, but it performs a bit better. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com> A question nevertheless: > --- a/xen/arch/x86/x86_64/kexec_reloc.S > +++ b/xen/arch/x86/x86_64/kexec_reloc.S > @@ -19,6 +19,7 @@ > #include <xen/kimage.h> > > #include <asm/asm_defns.h> > +#include <asm/cache.h> > #include <asm/msr-index.h> > #include <asm/page.h> > #include <asm/machine_kexec.h> > @@ -174,6 +175,9 @@ FUNC_LOCAL(compatibility_mode) > ud2 > END(compatibility_mode) > > + /* Separate code and data into into different cache lines */ > + .balign L1_CACHE_BYTES > + > DATA_LOCAL(compat_mode_gdt_desc, 4) > .word .Lcompat_mode_gdt_end - compat_mode_gdt -1 > .quad 0x0000000000000000 /* set in call_32_bit above */ Because of L1_CACHE_BYTES being 128, you indeed put at least 1 cache line in between. Is that necessary, though? Just starting data on the next cache line ought to be enough? IOW if and when we adjust L1_CACHE_BYTES, we won't need to touch this again, just that the title here then would end up slightly misleading. Jan
