Displaying 20 results from an estimated 4000 matches similar to: "[PATCH] Fix CONFIG_PARAVIRT for 2.6.19-rc5-mm1"
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
2007 Apr 18
2
[PATCH 1/3] Paravirtualization: Kernel Ring Cleanups
Hi all,
I've been looking at finding common ground between the VMI, Xen and
other paravirtualization approaches, and after some discussion, we're
getting somewhere.
These first two patches are the fundamentals, stolen mainly from the
VMI patches: removing assumptions about the kernel running in ring 0,
and macro-izing all the obvious para-virtualize-needing insns. The
third patch is
2007 Apr 18
2
[PATCH 1/3] Paravirtualization: Kernel Ring Cleanups
Hi all,
I've been looking at finding common ground between the VMI, Xen and
other paravirtualization approaches, and after some discussion, we're
getting somewhere.
These first two patches are the fundamentals, stolen mainly from the
VMI patches: removing assumptions about the kernel running in ring 0,
and macro-izing all the obvious para-virtualize-needing insns. The
third patch is
2005 Aug 15
3
[-mm PATCH 2/32] fs: fix-up schedule_timeout() usage
Description: Use schedule_timeout_{,un}interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size. Also use
helper functions to convert between human time units and jiffies rather
than constant HZ division to avoid rounding errors.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
fs/cifs/cifsfs.c | 7 ++-----
fs/cifs/connect.c
2007 Apr 18
5
[PATCH] paravirt.h
This version over last version:
(1) Gets rid of the no_paravirt.h header and leaves native ops in place
(with some reshuffling to keep then under one #ifdef).
(2) Fixes the "X crashes with CONFIG_PARAVIRT=y" bug.
(3) Puts __ex_table entry in paravirt iret.
Another followup patch implements binary patching...
Rusty.
===
Create a paravirt.h header for all the critical operations which
2007 Apr 18
5
[PATCH] paravirt.h
This version over last version:
(1) Gets rid of the no_paravirt.h header and leaves native ops in place
(with some reshuffling to keep then under one #ifdef).
(2) Fixes the "X crashes with CONFIG_PARAVIRT=y" bug.
(3) Puts __ex_table entry in paravirt iret.
Another followup patch implements binary patching...
Rusty.
===
Create a paravirt.h header for all the critical operations which
2007 Jul 09
1
[PATCH RFC] first cut at splitting up paravirt_ops
Here's a first attempt at splitting up paravirt_ops into more specific
chunks. Its pretty clunky and chunky; mostly just a lot of
replacement. The grouping of ops is very first cut; I'm open to
suggestions about what groups should exist and what ops they each should
contain.
The only slightly subtle part is that I've kept the structures wrapped
in a paravirt_ops structure,
2007 Jul 09
1
[PATCH RFC] first cut at splitting up paravirt_ops
Here's a first attempt at splitting up paravirt_ops into more specific
chunks. Its pretty clunky and chunky; mostly just a lot of
replacement. The grouping of ops is very first cut; I'm open to
suggestions about what groups should exist and what ops they each should
contain.
The only slightly subtle part is that I've kept the structures wrapped
in a paravirt_ops structure,
2007 Apr 18
3
[PATCH 1/2] paravirt.h header
OK, this is the revised paravirt.h (Andi has seen this before), then the
second is the binary patching stuff. More things get added to the
paravirt struct in future patches, but this basic stuff hasn't changed
for some time.
====
This patch does the dumbest possible replacement of paravirtualized
instructions: calls through a "paravirt_ops" structure. Currently
these are function
2007 Apr 18
3
[PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops
(Andrew, please sit these in the -mm tree for cooking)
Create a paravirt.h header for (almost) all the critical operations
which need to be replaced with hypervisor calls.
For the moment, this simply includes no_paravirt.h, where all the
native implementations now live.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Zachary Amsden <zach@vmware.com>
2007 Apr 18
3
[PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops
(Andrew, please sit these in the -mm tree for cooking)
Create a paravirt.h header for (almost) all the critical operations
which need to be replaced with hypervisor calls.
For the moment, this simply includes no_paravirt.h, where all the
native implementations now live.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Zachary Amsden <zach@vmware.com>
2007 Oct 09
2
[PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops
[ I think this is a straight repost this patch, which addresses all the
previous comments. I'd like to submit this for .24 as the basis for a
unified paravirt_ops. Any objections? ]
This patch refactors the paravirt_ops structure into groups of
functionally related ops:
pv_info - random info, rather than function entrypoints
pv_init_ops - functions used at boot time (some for module_init
2007 Oct 09
2
[PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops
[ I think this is a straight repost this patch, which addresses all the
previous comments. I'd like to submit this for .24 as the basis for a
unified paravirt_ops. Any objections? ]
This patch refactors the paravirt_ops structure into groups of
functionally related ops:
pv_info - random info, rather than function entrypoints
pv_init_ops - functions used at boot time (some for module_init
2007 Apr 18
1
[RFC, PATCH 12/24] i386 Vmi processor header
Fairly straight code motion. Split non-virtualizable pieces of
processor.h into default and VMI subarches. CPUID is
non-virtualizable, since it doesn't trap, and very often the
hypervisor will want to hide specific feature bits from the
kernel. To provide a replacement for call sites that use
CPUID as a serializing instruction, the sync_core() macro is
still available.
Signed-off-by:
2007 Apr 18
1
[RFC, PATCH 12/24] i386 Vmi processor header
Fairly straight code motion. Split non-virtualizable pieces of
processor.h into default and VMI subarches. CPUID is
non-virtualizable, since it doesn't trap, and very often the
hypervisor will want to hide specific feature bits from the
kernel. To provide a replacement for call sites that use
CPUID as a serializing instruction, the sync_core() macro is
still available.
Signed-off-by:
2007 Sep 28
2
[PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
This patch refactors the paravirt_ops structure into groups of
functionally related ops:
pv_info - random info, rather than function entrypoints
pv_init_ops - functions used at boot time (some for module_init too)
pv_misc_ops - lazy mode, which didn't fit well anywhere else
pv_time_ops - time-related functions
pv_cpu_ops - various privileged instruction ops
pv_irq_ops - operations for
2007 Sep 28
2
[PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
This patch refactors the paravirt_ops structure into groups of
functionally related ops:
pv_info - random info, rather than function entrypoints
pv_init_ops - functions used at boot time (some for module_init too)
pv_misc_ops - lazy mode, which didn't fit well anywhere else
pv_time_ops - time-related functions
pv_cpu_ops - various privileged instruction ops
pv_irq_ops - operations for
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:
>