search for: x86_feature_xenpv

...ntry_32.S > @@ -308,7 +308,8 @@ sysenter_past_esp: > > movl %esp, %eax > call do_fast_syscall_32 > - testl %eax, %eax > + /* XEN PV guests always use IRET path */ > + ALTERNATIVE "testl %eax, %eax", "xor %eax, %eax", X86_FEATURE_XENPV > jz .Lsyscall_32_done Could we make this a little less subtle: ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp .Lsyscasll_32_done", X86_FEATURE_XENPV Borislav, what do you think? Ditto for the others. > diff --git a/arch/x86/include/asm/cpufea...

...ntry_32.S > @@ -308,7 +308,8 @@ sysenter_past_esp: > > movl %esp, %eax > call do_fast_syscall_32 > - testl %eax, %eax > + /* XEN PV guests always use IRET path */ > + ALTERNATIVE "testl %eax, %eax", "xor %eax, %eax", X86_FEATURE_XENPV > jz .Lsyscall_32_done Could we make this a little less subtle: ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp .Lsyscasll_32_done", X86_FEATURE_XENPV Borislav, what do you think? Ditto for the others. > diff --git a/arch/x86/include/asm/cpufea...

.....901f186 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -308,7 +308,8 @@ sysenter_past_esp: movl %esp, %eax call do_fast_syscall_32 - testl %eax, %eax + /* XEN PV guests always use IRET path */ + ALTERNATIVE "testl %eax, %eax", "xor %eax, %eax", X86_FEATURE_XENPV jz .Lsyscall_32_done /* Opportunistic SYSEXIT */ diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index c320183..98893d9 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -121,7 +121,8 @@ sysenter_flags_fixed: movq %rsp,...

...+308,8 @@ sysenter_past_esp: >> >> movl %esp, %eax >> call do_fast_syscall_32 >> - testl %eax, %eax >> + /* XEN PV guests always use IRET path */ >> + ALTERNATIVE "testl %eax, %eax", "xor %eax, %eax", X86_FEATURE_XENPV >> jz .Lsyscall_32_done > > Could we make this a little less subtle: > > ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp > .Lsyscasll_32_done", X86_FEATURE_XENPV > > Borislav, what do you think? > > Ditto for the others....

...arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -443,8 +443,8 @@ ENTRY(entry_SYSENTER_32) movl %esp, %eax call do_fast_syscall_32 /* XEN PV guests always use IRET path */ - ALTERNATIVE "testl %eax, %eax; jz .Lsyscall_32_done", \ - "jmp .Lsyscall_32_done", X86_FEATURE_XENPV + #define JMP_IF_IRET testl %eax, %eax; jz .Lsyscall_32_done + ALTERNATIVE(JMP_IF_IRET, jmp .Lsyscall_32_done, X86_FEATURE_XENPV) /* Opportunistic SYSEXIT */ TRACE_IRQS_ON /* User mode traces as IRQs on. */ @@ -536,7 +536,7 @@ restore_all: TRACE_IRQS_IRET .Lrestore_all_notrace: #ifdef CO...

..._esp: >>> >>> movl %esp, %eax >>> call do_fast_syscall_32 >>> - testl %eax, %eax >>> + /* XEN PV guests always use IRET path */ >>> + ALTERNATIVE "testl %eax, %eax", "xor %eax, %eax", X86_FEATURE_XENPV >>> jz .Lsyscall_32_done >> >> Could we make this a little less subtle: >> >> ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp >> .Lsyscasll_32_done", X86_FEATURE_XENPV >> >> Borislav, what do you think? &...

...such a configuration, virtio has never worked and will > + * not work without an even larger kludge. Instead, enable > + * the DMA API if we're a Xen guest, which at least allows > + * all of the sensible Xen configurations to work correctly. > + */ > + return static_cpu_has(X86_FEATURE_XENPV); You want: if (xen_domain()) return true; Without the #if so we use the DMA API for all types of Xen guest on all architectures. David

...such a configuration, virtio has never worked and will > + * not work without an even larger kludge. Instead, enable > + * the DMA API if we're a Xen guest, which at least allows > + * all of the sensible Xen configurations to work correctly. > + */ > + return static_cpu_has(X86_FEATURE_XENPV); You want: if (xen_domain()) return true; Without the #if so we use the DMA API for all types of Xen guest on all architectures. David

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. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

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. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

...nd 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. v2: * patch both TEST and JZ intructions with a single JMP * Add magic prefix to X86_FEATURE_XENPV comment to avoid having it printed in /proc/cpuinfo * Clarify in commit messages why irq_enable_sysexit and usergs_sysret32 are removed Boris Ostrovsky (3): x86/xen: Avoid fast syscall path for Xen PV guests x86: irq_enable_sysexit pv op is no longer needed x86: usergs_sysret32 pv...

...nd 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. v2: * patch both TEST and JZ intructions with a single JMP * Add magic prefix to X86_FEATURE_XENPV comment to avoid having it printed in /proc/cpuinfo * Clarify in commit messages why irq_enable_sysexit and usergs_sysret32 are removed Boris Ostrovsky (3): x86/xen: Avoid fast syscall path for Xen PV guests x86: irq_enable_sysexit pv op is no longer needed x86: usergs_sysret32 pv...

...>> > + * not work without an even larger kludge. Instead, enable >> > + * the DMA API if we're a Xen guest, which at least allows >> > + * all of the sensible Xen configurations to work correctly. >> > + */ >> > + return static_cpu_has(X86_FEATURE_XENPV); >> >> You want: >> >> if (xen_domain()) >> return true; >> >> Without the #if so we use the DMA API for all types of Xen guest on all >> architectures. >> >> David > > I doubt HVM domains can have virtio devices. >...

...>> > + * not work without an even larger kludge. Instead, enable >> > + * the DMA API if we're a Xen guest, which at least allows >> > + * all of the sensible Xen configurations to work correctly. >> > + */ >> > + return static_cpu_has(X86_FEATURE_XENPV); >> >> You want: >> >> if (xen_domain()) >> return true; >> >> Without the #if so we use the DMA API for all types of Xen guest on all >> architectures. >> >> David > > I doubt HVM domains can have virtio devices. >...

...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 whic...

...the same time. On + * such a configuration, virtio has never worked and will + * not work without an even larger kludge. Instead, enable + * the DMA API if we're a Xen guest, which at least allows + * all of the sensible Xen configurations to work correctly. + */ + return static_cpu_has(X86_FEATURE_XENPV); +#endif + return false; } -- 2.5.0

...tio has never worked and will > > + * not work without an even larger kludge. Instead, enable > > + * the DMA API if we're a Xen guest, which at least allows > > + * all of the sensible Xen configurations to work correctly. > > + */ > > + return static_cpu_has(X86_FEATURE_XENPV); > > You want: > > if (xen_domain()) > return true; > > Without the #if so we use the DMA API for all types of Xen guest on all > architectures. > > David I doubt HVM domains can have virtio devices. -- MST

...not work without an even larger kludge. Instead, enable > >> > + * the DMA API if we're a Xen guest, which at least allows > >> > + * all of the sensible Xen configurations to work correctly. > >> > + */ > >> > + return static_cpu_has(X86_FEATURE_XENPV); > >> > >> You want: > >> > >> if (xen_domain()) > >> return true; > >> > >> Without the #if so we use the DMA API for all types of Xen guest on all > >> architectures. > >> > >> David > > &...

...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 whic...

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases