similar to: Patch from LKML

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

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

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

[ 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

[ 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

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,

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,

Hi folks, With this series, the bulk of the work of pvops64 is done. Here, I integrate most of the paravirt.c and paravirt.h files, making them applicable to both architectures. CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page table integration (patches currently being worked on by Jeremy). Enjoy

Hi folks, With this series, the bulk of the work of pvops64 is done. Here, I integrate most of the paravirt.c and paravirt.h files, making them applicable to both architectures. CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page table integration (patches currently being worked on by Jeremy). Enjoy

The only member of that structure is startup_ipi_hook which is always set to paravirt_nop. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 9 --------- arch/x86/include/asm/paravirt_types.h | 10 ---------- arch/x86/include/asm/smp.h | 3 --- arch/x86/kernel/paravirt.c | 8 -------- arch/x86/kernel/smpboot.c

The only member of that structure is startup_ipi_hook which is always set to paravirt_nop. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 9 --------- arch/x86/include/asm/paravirt_types.h | 10 ---------- arch/x86/include/asm/smp.h | 3 --- arch/x86/kernel/paravirt.c | 8 -------- arch/x86/kernel/smpboot.c

Hi Peter, Removal of VMI(VMware's para-virtualization technique) is scheduled for 2.6.37, I was wondering what would be the right time frame for submitting a patch which does that. Does the x86-tip tree have any next branch where we can park this patch ? Below is the patch for your reference which just removes VMI specific bits, applies on top of x86-tip. There is also an opportunity to

Hi Peter, Removal of VMI(VMware's para-virtualization technique) is scheduled for 2.6.37, I was wondering what would be the right time frame for submitting a patch which does that. Does the x86-tip tree have any next branch where we can park this patch ? Below is the patch for your reference which just removes VMI specific bits, applies on top of x86-tip. There is also an opportunity to

since the pv_apic_ops are only present if CONFIG_X86_LOCAL_APIC is compiled in, kvmclock failed to build without this option. This patch fixes this Signed-off-by: Glauber Costa <gcosta at redhat.com> --- arch/x86/kernel/kvmclock.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index ddee040..4bc1be5 100644

Hi, We ran a few experiments to compare performance of VMware's paravirtualization technique (VMI) and hardware MMU technologies (HWMMU) on VMware's hypervisor. To give some background, VMI is VMware's paravirtualization specification which tries to optimize CPU and MMU operations of the guest operating system. For more information take a look at this

Hi, We ran a few experiments to compare performance of VMware's paravirtualization technique (VMI) and hardware MMU technologies (HWMMU) on VMware's hypervisor. To give some background, VMI is VMware's paravirtualization specification which tries to optimize CPU and MMU operations of the guest operating system. For more information take a look at this

Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This

Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This