similar to: [PATCH 1/3] Virtualization config cleanup: Select CONFIG_PARAVIRT when required

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

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

Group all the "guest OS" support options together, under CONFIG_PARAVIRT. Make this a proper menu item so it looks neater on menuconfig etc, and make the wording for each prompt uniform. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 3d3ac181380b arch/i386/Kconfig --- a/arch/i386/Kconfig Fri Sep 14 12:24:15 2007 +1000 +++ b/arch/i386/Kconfig Fri Sep 14 12:45:09

Group all the "guest OS" support options together, under CONFIG_PARAVIRT. Make this a proper menu item so it looks neater on menuconfig etc, and make the wording for each prompt uniform. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 3d3ac181380b arch/i386/Kconfig --- a/arch/i386/Kconfig Fri Sep 14 12:24:15 2007 +1000 +++ b/arch/i386/Kconfig Fri Sep 14 12:45:09

Any objections? Rusty. === Having KVM appear in the middle of "drivers" is kinda strange, and having it alone under a menu called "virtualization" doubly so. 1) Move the "Virtualization" menu into the arch-specific i386 and x86-64 Kconfig. 2) Add a help message to the menu. 3) Move CONFIG_PARAVIRT under CONFIG_VIRTUALIZATION 4) Move lguest into same menu.

Any objections? Rusty. === Having KVM appear in the middle of "drivers" is kinda strange, and having it alone under a menu called "virtualization" doubly so. 1) Move the "Virtualization" menu into the arch-specific i386 and x86-64 Kconfig. 2) Add a help message to the menu. 3) Move CONFIG_PARAVIRT under CONFIG_VIRTUALIZATION 4) Move lguest into same menu.

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,

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

The ARM platform has no concept of PVMMU and therefor no HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out when not required. In some similar situations (e.g. P2M) we have defined dummy functions to avoid this, however I think we can/should draw the line at dummying out actual hypercalls. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- arch/x86/xen/Kconfig

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

The TSC register is a requirement when running under Xen, but that's going to be present on any CPU which can boot Xen. We don't need any of the kernel's TSC machinery, since the usage is contained within the Xen interfaces, and therefore XEN does not need to depend on CONFIG_X86_TSC. Signed-off-by: Ian Campbell <ian.campbell at citrix.com> --- arch/x86/xen/Kconfig | 2 +- 1