> On Nov 14, 2020, at 10:33 PM, Jürgen Groß <jgr...@suse.com> wrote: > > On 14.11.20 19:10, Andy Lutomirski wrote: >>> On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß <jgr...@suse.com> wrote: >>> >>> On 13.11.20 18:34, Andy Lutomirski wrote: >>>> On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper >>>> <andrew.coop...@citrix.com> wrote: >>>> >>>> So I think there is at most one of these that wants anything more >>>> complicated than a plain ALTERNATIVE. Any volunteers to make it so? >>>> Juergen, if you do all of them except USERGS_SYSRET64, I hereby >>>> volunteer to do that one. >>> >>> Why is a plain alternative (either swapgs; sysretq or a jmp xen_sysret64 >>> depending on X86_FEATURE_XENPV) no option? >>> >>> Its not as if this code would run before alternative patching. >> ALTERNATIVE would "work" in the sense that it would function and be >> just about as nonsensical as the current code. Fundamentally, Xen >> PV's sysret feature is not a drop-in replacement for SYSRET64, and >> pretending that it is seems unlikely to work well. I suspect that the >> current code is some combination of exceedingly slow, non-functional, >> and incorrect in subtle ways. >> We should just have a separate Xen PV exit path the same way we have a >> separate entry path in recent kernels. *This* is what I'm >> volunteering to do. > > I don't think there is much work needed. Xen PV does basically a return > to user mode via IRET. I think it might work just to use > swapgs_restore_regs_and_return_to_usermode() unconditionally for Xen PV. >
I’m quite confident that will work, but I was hoping to get it to work quickly too :) > > Juergen > <OpenPGP_0xB0DE9DD628BF132F.asc>