On 15.11.20 17:05, Andy Lutomirski wrote:
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 :)
The PV interface requires to use the iret hypercall, because there is no sysret equivalent. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature