search for: paravirt_xxl

A large amount of paravirt ops is used by Xen PV guests only. Add a new config option PARAVIRT_XXL which is selected by XEN_PV. Later we can put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/Kconfig | 3 +++ arch/x86/xen/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/x86/Kconfig b/arch...

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On 08/10/2018 07:52 AM, Juergen Gross wrote: > A large amount of paravirt ops is used by Xen PV guests only. Add a new > config option PARAVIRT_XXL which is selected by XEN_PV. Later we can > put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella. What does "XXL" stand for? My immediate thought was "extra extra large" but I suspect it's something else. -boris

...0xd8 }, // mov %eax, %cr3 >> - .irq_restore_fl = { 0x50, 0x9d }, // push %eax; popf >> - .cpu_iret = { 0xcf }, // iret >> -# endif > > I was looking at x86_64 paravirt the other day and found we actually > have pv_ops.cpu.iret users there.. On x86_64 we have (without PARAVIRT_XXL): #define INTERRUPT_RETURN jmp native_iret and with PARAVIRT_XXL this is basically a jmp *pv_ops.cpu.iret which will then be patched to either jmp native_iret or jmp xen_iret. On x86_32 INTERRUPT_RETURN was just "iret" for the non-paravirt case. This is the reason for above drop...

On 8/7/20 4:38 AM, Juergen Gross wrote: > @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) > { > pteval_t ret; > > - if (sizeof(pteval_t) > sizeof(long)) > - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); > - else > - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >

On 09.08.20 04:34, Boris Ostrovsky wrote: > On 8/7/20 4:38 AM, Juergen Gross wrote: >> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) >> { >> pteval_t ret; >> >> - if (sizeof(pteval_t) > sizeof(long)) >> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); >> - else >> - ret = PVOP_CALLEE1(pteval_t,

On 8/10/20 12:39 AM, J?rgen Gro? wrote: > On 09.08.20 04:34, Boris Ostrovsky wrote: >> On 8/7/20 4:38 AM, Juergen Gross wrote: >>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) >>> ? { >>> ????? pteval_t ret; >>> ? -??? if (sizeof(pteval_t) > sizeof(long)) >>> -??????? ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val

On 8/7/20 4:38 AM, Juergen Gross wrote: > @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) > { > pteval_t ret; > > - if (sizeof(pteval_t) > sizeof(long)) > - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); > - else > - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 92 +++------------------ arch/x86/include/asm/paravirt_types.h | 21 ----- arch/x86/include/...

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 120 ++------------------ arch/x86/include/asm/paravirt_types.h | 21 ---- arch/x86/include...

...ort alive in the Linux kernel. Additionally Meltdown mitigation is not available in the kernel running as 32-bit PV guest, so dropping this mode makes sense from security point of view, too. Juergen Gross (2): x86/xen: remove 32-bit Xen PV guest support x86/paravirt: remove 32-bit support from PARAVIRT_XXL arch/x86/entry/entry_32.S | 93 -------- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 105 +-------- arch/x86/include/asm/paravirt_types.h | 20 -- arch/x86/include/asm/pgtable-3level_types.h | 5 - arch/x86/include...

...ort alive in the Linux kernel. Additionally Meltdown mitigation is not available in the kernel running as 32-bit PV guest, so dropping this mode makes sense from security point of view, too. Juergen Gross (2): x86/xen: remove 32-bit Xen PV guest support x86/paravirt: remove 32-bit support from PARAVIRT_XXL arch/x86/entry/entry_32.S | 93 -------- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 105 +-------- arch/x86/include/asm/paravirt_types.h | 20 -- arch/x86/include/asm/pgtable-3level_types.h | 5 - arch/x86/include...

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests") is a prerequisite for this series. The l...

...Additionally Meltdown mitigation is not available in the kernel running > as 32-bit PV guest, so dropping this mode makes sense from security > point of view, too. > > Juergen Gross (2): > x86/xen: remove 32-bit Xen PV guest support > x86/paravirt: remove 32-bit support from PARAVIRT_XXL Hooray!

...lver wrote: >>> On Fri, 7 Aug 2020 at 14:04, J?rgen Gro? <jgross at suse.com> wrote: >>>> >>>> On 07.08.20 13:38, Marco Elver wrote: >>>>> On Fri, Aug 07, 2020 at 12:35PM +0200, J?rgen Gro? wrote: > ... >>>>>> I think CONFIG_PARAVIRT_XXL shouldn't matter, but I'm not completely >>>>>> sure about that. CONFIG_PARAVIRT_SPINLOCKS would be my primary suspect. >>>>> >>>>> Yes, PARAVIRT_XXL doesn't make a different. When disabling >>>>> PARAVIRT_SPINLOCKS, however...

...t; >>>>> Never mind, I get these warnings even if I don't turn on KCSAN >>>>> (CONFIG_KCSAN=n). Something else is going on with PARAVIRT=y that >>>>> throws off IRQ state tracking. :-/ >>>> >>>> What are the settings of CONFIG_PARAVIRT_XXL and >>>> CONFIG_PARAVIRT_SPINLOCKS in this case? >>> >>> I attached a config. >>> >>> $> grep PARAVIRT .config >>> CONFIG_PARAVIRT=y >>> CONFIG_PARAVIRT_XXL=y >>> # CONFIG_PARAVIRT_DEBUG is not set >>> CONFI...

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests") is a prerequisite for this series. The l...

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00