On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß <jgross@xxxxxxxx> wrote:
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> 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.
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature