similar to: Why disable vdso by default with CONFIG_PARAVIRT?

On Mon, 2007-03-05 at 13:06 +0100, Ingo Molnar wrote: > Subject: [patch] paravirt: VDSO page is essential > From: Ingo Molnar <mingo@elte.hu> > > commit 3bbf54725467d604698721384d858b5983b87e8f disables the VDSO for > CONFIG_PARAVIRT kernels. This #ifdeffery was a bad change: the VDSO is > an essential component of Linux, and this change forces all of them to > use

On Mon, 2007-03-05 at 13:06 +0100, Ingo Molnar wrote: > Subject: [patch] paravirt: VDSO page is essential > From: Ingo Molnar <mingo@elte.hu> > > commit 3bbf54725467d604698721384d858b5983b87e8f disables the VDSO for > CONFIG_PARAVIRT kernels. This #ifdeffery was a bad change: the VDSO is > an essential component of Linux, and this change forces all of them to > use

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the

Paravirt-ops guests which move the fixmap also end up moving the syscall = VDSO. This fails if it is prelinked at a fixed address, which is why = COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN). = Several options are available to try to address this. Jan had cooked up = a patch for Xen that used build magic to find the parts of the VDSO that = need relocation. I

Paravirt-ops guests which move the fixmap also end up moving the syscall = VDSO. This fails if it is prelinked at a fixed address, which is why = COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN). = Several options are available to try to address this. Jan had cooked up = a patch for Xen that used build magic to find the parts of the VDSO that = need relocation. I

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

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

VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be too radical to consider at this stage in the release of 2.6.21. We don't expect this config option to be turned on by

VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be too radical to consider at this stage in the release of 2.6.21. We don't expect this config option to be turned on by

Chris said, and I agree, that we should try to get the basic PV-ops infrastructure stuff into 2.6.19. To me this means being able to run a kernel native with CONFIG_PARAVIRT, and see little or no functional or performance degradation. What do we need to do to get there: * fix the slowdown bug, which seems to be something to do with rdmsr/wrmsr on SMP systems * work out how to

Chris said, and I agree, that we should try to get the basic PV-ops infrastructure stuff into 2.6.19. To me this means being able to run a kernel native with CONFIG_PARAVIRT, and see little or no functional or performance degradation. What do we need to do to get there: * fix the slowdown bug, which seems to be something to do with rdmsr/wrmsr on SMP systems * work out how to

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This fixes various problems that cropped up with the vdso patches. - Patch 1 fixes an information leak to userspace. - Patches 2 and 3 fix the kernel build on gold. - Patches 4 and 5 fix Xen (I hope). Konrad, could you could test these on Xen and run 'test_vsyscall test' [1]? I don't have a usable Xen setup. Also, I'd appreciate a review of patches 4 and 5 from some