[lkml]   [2020]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: WARNING: can't access registers at asm_common_interrupt
On 14.11.20 19:10, Andy Lutomirski wrote:
> On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß <> wrote:
>> On 13.11.20 18:34, Andy Lutomirski wrote:
>>> On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
>>> <> 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.

[unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2020-11-15 07:34    [W:0.107 / U:9.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site