similar to: [patch] paravirt: VDSO page is essential

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

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

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

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 =================================================================== ---

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

So, is everyone happy with this smerge of Ingo and Gerd's work? Reposted below. Thanks, Rusty. -------- Forwarded Message -------- From: Linus Torvalds <torvalds@osdl.org> To: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@osdl.org> Subject: Re: [Fwd: [Fwd: FW: argh]] Date: Wed, 17 May 2006 21:35:51 -0700 (PDT) On Thu, 18 May 2006, Rusty Russell wrote: >

So, is everyone happy with this smerge of Ingo and Gerd's work? Reposted below. Thanks, Rusty. -------- Forwarded Message -------- From: Linus Torvalds <torvalds@osdl.org> To: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@osdl.org> Subject: Re: [Fwd: [Fwd: FW: argh]] Date: Wed, 17 May 2006 21:35:51 -0700 (PDT) On Thu, 18 May 2006, Rusty Russell wrote: >

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

Hi Andi, What problem do they cause together? There's certainly no problem with Xen+vdso (in fact, its actually very useful so that it picks up the right libc with Xen-friendly TLS). J

Hi Andi, What problem do they cause together? There's certainly no problem with Xen+vdso (in fact, its actually very useful so that it picks up the right libc with Xen-friendly TLS). J

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

On Fri, 14 Sep 2018, Arnd Bergmann wrote: > On Fri, Sep 14, 2018 at 2:52 PM Thomas Gleixner <tglx at linutronix.de> wrote: > A couple of architectures (s390, ia64, riscv, powerpc, arm64) > implement the vdso as assembler code at the moment, so they > won't be as easy to consolidate (other than outright replacing all > the code). > > The other five: >