Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1292529 > unrolled thread

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit Andrew Cooper <andrew.cooper3@citrix.com> - 2015-12-15 21:50 +0100
    Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit Andy Lutomirski <luto@amacapital.net> - 2015-12-15 22:30 +0100

#1292529 — Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On 19/11/15 22:07, Andy Lutomirski wrote:
> On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the
>> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
>> (and sysret32 in compat mode) pv ops, as suggested by Andy.
>>
>> As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not
>> used anymore by anyone and so can be removed.
> This whole series is:
>
> Acked-by: Andy Lutomirski <luto@kernel.org>
>
> Now I just have to sucker someone into getting rid of
> PARAVIRT_ADJUST_EXCEPTION_FRAME (by using stub entries) and the
> overcomplicated syscall entry stuff.  :)

Looking at this, it should be quite easy now.

ALTERNATIVE "", "pop %rcx; %pop %11", X86_FEATURE_XENPV

(Completely untested)

> And whoever gets rid of
> PARAVIRT_ADJUST_EXCEPTION_FRAME gets to wonder why it doesn't crash
> and burn for NMIs on Xen, since I'm reasonably confident that it can't
> possibly be correct.

The Xen PV ABI only has a single kernel stack pointer which may be
registered.  There is no equivalent of an IST, so if a second fault
occurs, it is delivered normally on the current stack.

By the looks of it, the other NMI handling is ambivalent to the fact
that it isn't really on an IST stack under Xen.

~Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1292553

On Tue, Dec 15, 2015 at 12:40 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 19/11/15 22:07, Andy Lutomirski wrote:
>> On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky
>> <boris.ostrovsky@oracle.com> wrote:
>>> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the
>>> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
>>> (and sysret32 in compat mode) pv ops, as suggested by Andy.
>>>
>>> As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not
>>> used anymore by anyone and so can be removed.
>> This whole series is:
>>
>> Acked-by: Andy Lutomirski <luto@kernel.org>
>>
>> Now I just have to sucker someone into getting rid of
>> PARAVIRT_ADJUST_EXCEPTION_FRAME (by using stub entries) and the
>> overcomplicated syscall entry stuff.  :)
>
> Looking at this, it should be quite easy now.
>
> ALTERNATIVE "", "pop %rcx; %pop %11", X86_FEATURE_XENPV
>
> (Completely untested)

Can't we do one better, though?  Generate a pile of stubs that do the
pops and jump into the normal native asm path.  Admittedly, that's a
lot more work, and I think that the ALTERNATIVE thing you're
suggesting would be a nice improvement.

>
>> And whoever gets rid of
>> PARAVIRT_ADJUST_EXCEPTION_FRAME gets to wonder why it doesn't crash
>> and burn for NMIs on Xen, since I'm reasonably confident that it can't
>> possibly be correct.
>
> The Xen PV ABI only has a single kernel stack pointer which may be
> registered.  There is no equivalent of an IST, so if a second fault
> occurs, it is delivered normally on the current stack.
>
> By the looks of it, the other NMI handling is ambivalent to the fact
> that it isn't really on an IST stack under Xen.

I'll try to find some time to look at it.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web