On 20/02/2023 11:51 am, Ross Lagerwall wrote: >> From: Andrew Cooper <[email protected]> >> Sent: Monday, February 20, 2023 11:04 AM >> To: Xen-devel <[email protected]> >> Cc: Andrew Cooper <[email protected]>; Jan Beulich >> <[email protected]>; Roger Pau Monne <[email protected]>; Wei Liu >> <[email protected]>; Konrad Rzeszutek Wilk <[email protected]>; Ross >> Lagerwall <[email protected]> >> 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
