similar to: [PATCH 0/4] paravirt_ops-64 compile fixes

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

A lot of cleanup after removal of 32-bit Xen PV guest support in paravirt code. Changes in V4: - dropped patches 1-3, as already committed - addressed comments to V3 - added new patches 5+6 Changes in V3: - addressed comments to V2 - split patch 1 into 2 patches - new patches 3 and 7 Changes in V2: - rebase to 5.8 kernel - addressed comments to V1 - new patches 3 and 4 Juergen Gross (6):

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

Introduce the basic VMI sub-arch configuration dependencies. VMI kernels only are designed to run on modern hardware platforms. As such, they require a working APIC, and do not support some legacy functionality, including APM BIOS, ISA and MCA bus systems, PCI BIOS interfaces, or PnP BIOS (by implication of dropping ISA support). They also require a P6 series CPU. Signed-off-by: Zachary Amsden

Introduce the basic VMI sub-arch configuration dependencies. VMI kernels only are designed to run on modern hardware platforms. As such, they require a working APIC, and do not support some legacy functionality, including APM BIOS, ISA and MCA bus systems, PCI BIOS interfaces, or PnP BIOS (by implication of dropping ISA support). They also require a P6 series CPU. Signed-off-by: Zachary Amsden

(Unless there are complaints, I'll push this as part of the lguest patches for 2.6.24, since there are lguest config changes there too). Andi points out that PARAVIRT is an option best selected when needed. We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT if the user turns on anything which needs it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> ---

(Unless there are complaints, I'll push this as part of the lguest patches for 2.6.24, since there are lguest config changes there too). Andi points out that PARAVIRT is an option best selected when needed. We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT if the user turns on anything which needs it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> ---

Given all the discussion, let's just require NO_HZ when CONFIG_PARAVIRT. Anyone object? Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- --- a/arch/i386/Kconfig Mon Mar 12 11:07:45 2007 -0700 +++ b/arch/i386/Kconfig Mon Mar 12 16:53:14 2007 -0700 @@ -208,7 +208,7 @@ endchoice config PARAVIRT bool "Paravirtualization support (EXPERIMENTAL)" - depends on EXPERIMENTAL

Given all the discussion, let's just require NO_HZ when CONFIG_PARAVIRT. Anyone object? Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- --- a/arch/i386/Kconfig Mon Mar 12 11:07:45 2007 -0700 +++ b/arch/i386/Kconfig Mon Mar 12 16:53:14 2007 -0700 @@ -208,7 +208,7 @@ endchoice config PARAVIRT bool "Paravirtualization support (EXPERIMENTAL)" - depends on EXPERIMENTAL

From: Randy Dunlap <randy.dunlap@oracle.com> Since Voyager and Visual WS already define ARCH_SETUP, it looks like PARAVIRT shouldn't be offered for them. In file included from arch/i386/kernel/setup.c:63: include/asm-i386/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefined In file included from include/asm/msr.h:5, from include/asm/processor.h:17,

From: Randy Dunlap <randy.dunlap@oracle.com> Since Voyager and Visual WS already define ARCH_SETUP, it looks like PARAVIRT shouldn't be offered for them. In file included from arch/i386/kernel/setup.c:63: include/asm-i386/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefined In file included from include/asm/msr.h:5, from include/asm/processor.h:17,

On Mon, Jul 28, 2014 at 12:18:10PM -0700, H. Peter Anvin wrote: > On 07/28/2014 12:04 PM, Eduardo Habkost wrote: > > When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on > > the {rd,wr}msr instructions. This makes serious issues (either on the > > guest kernel, or on the host) be silently ignored, and is different from > > the native MSR code (which does

On Mon, Jul 28, 2014 at 12:18:10PM -0700, H. Peter Anvin wrote: > On 07/28/2014 12:04 PM, Eduardo Habkost wrote: > > When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on > > the {rd,wr}msr instructions. This makes serious issues (either on the > > guest kernel, or on the host) be silently ignored, and is different from > > the native MSR code (which does

Hey folks, This is the part-of-pvops-implementation-that-is-not-exactly-a-merge. Neat, uh? This is the majority of the work. The first patch in the series does not really belong here. It was already sent to lkml separetedly before, but I'm including it again, for a very simple reason: Try to test the paravirt patches without it, and you'll fail miserably ;-) (and it was not yet