| Message ID | 20231120195742.1343677-1-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/entry: Use 32bit XOR in handle_ist_exception | expand |
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 <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> 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. Jan
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 <andrew.cooper3@citrix.com> > Reviewed-by: Jan Beulich <jbeulich@suse.com> 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
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S index b53d862089d7..cb794167c127 100644 --- 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
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 <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Wei Liu <wl@xen.org> --- xen/arch/x86/x86_64/entry.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: fa2da5bce90b3777aa7a323e1cf201c97b56d278 prerequisite-patch-id: a9e4e1e34d08e876d1fcb3299c6d563086768722 prerequisite-patch-id: 703590f2c99382f6509c94bb5955f47ab2d7c57d