Displaying 20 results from an estimated 1100 matches similar to: "[PATCH, experimental] i386 Allow the fixmap to be relocated at boot time"
2007 Apr 18
2
[RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT
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
2007 Apr 18
2
[RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT
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
2007 Apr 18
2
[PATCH] exec-shield style vdso move.
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:
>
2007 Apr 18
2
[PATCH] exec-shield style vdso move.
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:
>
2007 Apr 18
1
[PATCH] Gerd Hoffman's move-vsyscall-into-user-address-range patch
AFAICT we'll pay one extra TLB entry for this patch. Zach had a patch
which left the vsyscall page at the top of memory (minus hole for
hypervisor) and patched the ELF header at boot.
Thoughts welcome,
Rusty.
Name: Move vsyscall page out of fixmap, above stack
Author: Gerd Hoffmann <kraxel@suse.de>
Hypervisors want to use memory at the top of the address space
(eg. 64MB for Xen, or
2007 Apr 18
1
[PATCH] Gerd Hoffman's move-vsyscall-into-user-address-range patch
AFAICT we'll pay one extra TLB entry for this patch. Zach had a patch
which left the vsyscall page at the top of memory (minus hole for
hypervisor) and patched the ELF header at boot.
Thoughts welcome,
Rusty.
Name: Move vsyscall page out of fixmap, above stack
Author: Gerd Hoffmann <kraxel@suse.de>
Hypervisors want to use memory at the top of the address space
(eg. 64MB for Xen, or
2018 May 23
0
[PATCH v3 23/27] x86/modules: Adapt module loading for PIE support
Adapt module loading to support PIE relocations. Generate dynamic GOT if
a symbol requires it but no entry exist in the kernel GOT.
Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.
Signed-off-by: Thomas Garnier <thgarnie at google.com>
---
arch/x86/Makefile | 4 +
arch/x86/include/asm/module.h
2017 Oct 04
1
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls
to pv_irq_ops function pointers, like:
callq *0xffffffff81e3a400 (pv_irq_ops.save_fl)
In non-Xen paravirt environments -- including native, KVM, Hyper-V, and
VMware -- the above code gets patched by native_patch() to look like
this instead:
pushfq
pop %rax
nopl 0x0(%rax,%rax,1)
So in most scenarios,
2007 Apr 18
1
[PATCH 5/5] Create a hole in high linear address space
Allow compile time creation of a hole at the high end of linear address space.
This makes accomodating a hypervisor a much more tractable problem by giving
it ample playground to live in. Currently, the hole size is fixed at config
time; I have experimented with dynamically sized holes, and have a later
patch that developes this potential, but it becomes much more useful once
the exact
2007 Apr 18
1
[PATCH 5/5] Create a hole in high linear address space
Allow compile time creation of a hole at the high end of linear address space.
This makes accomodating a hypervisor a much more tractable problem by giving
it ample playground to live in. Currently, the hole size is fixed at config
time; I have experimented with dynamically sized holes, and have a later
patch that developes this potential, but it becomes much more useful once
the exact
2007 Apr 18
1
[PATCH] (with benchmarks) binary patching of paravirt_ops call sites
Hi all,
Sorry for the delay. This implements binary patching of call sites for
interrupt-related paravirt ops, since no-doubt Andi wasn't the only one
to believe this approach is slow.
The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM.
2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4
CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the
difference
2007 Apr 18
1
[PATCH] (with benchmarks) binary patching of paravirt_ops call sites
Hi all,
Sorry for the delay. This implements binary patching of call sites for
interrupt-related paravirt ops, since no-doubt Andi wasn't the only one
to believe this approach is slow.
The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM.
2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4
CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the
difference
2023 Jun 10
0
[PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP
On Thu, Jun 08 2023 at 17:33, Hou Wenlong wrote:
> On Wed, Jun 07, 2023 at 08:49:15PM +0800, Dave Hansen wrote:
>> What problems does this patch set solve? How might that solution be
>> visible to end users? Why is this problem important to you?
>
> We want to build the kernel as PIE and allow the kernel image area,
> including the fixmap area, to be placed at any virtual
2011 Jul 18
2
[PATCH tip/x86/mm] x86_32: calculate additional memory needed by the fixmap
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
When NR_CPUS increases the fixmap might need more than the page
allocated by head_32.S.
This patch introduces the logic to calculate the additional memory that
is going to be required by early_ioremap_page_table_range_init:
- enough memory to allocate the pte pages needed to cover the fixmap
virtual memory range, minus the single
2007 Apr 18
1
[RFC, PATCH 7/24] i386 Vmi memory hole
Create a configurable hole in the linear address space at the top
of memory. A more advanced interface is needed to negotiate how
much space the hypervisor is allowed to steal, but in the end, it
seems most likely that a fixed constant size will be chosen for
the compiled kernel, potentially propagated to an information
page used by paravirtual initialization to determine interface
compatibility.
2007 Apr 18
1
[RFC, PATCH 7/24] i386 Vmi memory hole
Create a configurable hole in the linear address space at the top
of memory. A more advanced interface is needed to negotiate how
much space the hypervisor is allowed to steal, but in the end, it
seems most likely that a fixed constant size will be chosen for
the compiled kernel, potentially propagated to an information
page used by paravirtual initialization to determine interface
compatibility.
2007 Apr 18
3
[patch] paravirt: VDSO page is essential
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
2007 Apr 18
3
[patch] paravirt: VDSO page is essential
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
2005 Dec 03
3
i386 domU on amd64 (xen-unstable)
Hi,
I want to run a i386 domU on my AMD64. I created a LVM partition with Debian
Sarge i386 on it, and set everything up. Now for the compilation of the
kernel
for i386. In "linux-2.6.12-xenU/" , make ARCH=xen menuconfig, i did:
Processor Type (X86) (which was selected, and compiled with X86_64
before)
Processor family (Opteron/Athlon64/Hammer/K8)
[*] Generic x86 support
if
2005 Dec 03
3
i386 domU on amd64 (xen-unstable)
Hi,
I want to run a i386 domU on my AMD64. I created a LVM partition with Debian
Sarge i386 on it, and set everything up. Now for the compilation of the
kernel
for i386. In "linux-2.6.12-xenU/" , make ARCH=xen menuconfig, i did:
Processor Type (X86) (which was selected, and compiled with X86_64
before)
Processor family (Opteron/Athlon64/Hammer/K8)
[*] Generic x86 support
if