On 20/02/2023 11:51 am, Ross Lagerwall wrote: >> From: Andrew Cooper <andrew.coop...@citrix.com> >> Sent: Monday, February 20, 2023 11:04 AM >> To: Xen-devel <xen-devel@lists.xenproject.org> >> Cc: Andrew Cooper <andrew.coop...@citrix.com>; Jan Beulich >> <jbeul...@suse.com>; Roger Pau Monne <roger....@citrix.com>; Wei Liu >> <w...@xen.org>; Konrad Rzeszutek Wilk <konrad.w...@oracle.com>; Ross >> Lagerwall <ross.lagerw...@citrix.com> >> Subject: [PATCH] x86/asm: ELF metadata for simple cases >> >> This is generally good practice, and necessary for livepatch binary diffing >> to >> work. >> >> With this, livepatching of the SVM entry path works. The only complication >> is >> with svm_stgi_label which is only used by oprofile to guestimate (not >> completely correctly) when an NMI hit guest context. >> >> Livepatching of VMX is still an open question, because the logic doesn't form >> anything remotely resembling functions. Both code fragments jump into each >> other so need to be updated in tandem. Also, both code fragment entries need >> trampolines in the case that patching actually occurs. For now, just treat >> it >> as a single function. > If it is treated as two functions and both functions are always included in > the live patch, would that work?
I think so, but only because the first jumped-to label in vmx_asm_do_vmentry is beyond the trampoline. But I guess the question is how to tie the two symbols together. We don't want to be hardcoding this in livepatch-build-tools IMO. Perhaps we want a CONFIG_LIVEPATCH build of Xen to include a section/note/something identifying "grouped symbols", meaning "if there's a delta in one, include all even if they haven't changed" ? I'm getting the distinct impression that we're going to need it it for the PV entry/exit paths too. ~Andrew
