On 21/11/2023 8:56 am, Jan Beulich wrote: > On 20.11.2023 20:57, Andrew Cooper wrote: >> This is a micro-optimsiation for Silvermont microarchitectures, which don't >> recognise the 64bit form as a zeroing idiom. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper <[email protected]> > Reviewed-by: Jan Beulich <[email protected]>
Thanks. > > For my education, ... > >> --- a/xen/arch/x86/x86_64/entry.S >> +++ b/xen/arch/x86/x86_64/entry.S >> @@ -1027,7 +1027,7 @@ handle_ist_exception: >> * Interrupted guest context. Clear the restore value for xen_cr3 >> * and copy the context to stack bottom. >> */ >> - xor %r15, %r15 >> + xor %r15d, %r15d >> xor %ebx, %ebx >> GET_CPUINFO_FIELD(guest_cpu_user_regs,di) >> movq %rsp,%rsi >> >> base-commit: fa2da5bce90b3777aa7a323e1cf201c97b56d278 > ... while I understand this, what ... > >> prerequisite-patch-id: a9e4e1e34d08e876d1fcb3299c6d563086768722 >> prerequisite-patch-id: 703590f2c99382f6509c94bb5955f47ab2d7c57d > ... are these about? They look like they would be naming prereq changes > which aren't committed yet, but (a) base-commit names the tip of the > staging branch and (b) the hashes would be meaningless without a repo > reference if they pointed at something that wasn't committed yet. It's a slightly irritating side-effect of the functionality that generates base-commit. What it means was that this patch was 2 commits deep into a branch and I haven't sent out the other two patches. In this case, misc debugging that's not relevant to the change at all. I try to strip it when I remember, but I forgot in this case. ~Andrew
