similar to: [PATCH RFC] paravirt: cleanup lazy mode handling

[ 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? ] Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This

[ 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? ] Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

[ 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

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

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

When Zach Amsden added PARAVIRT_LAZY_FLUSH I didn't realize how often it would get called. We only need to do something if we're actually in lazy mode. Before: Time for one context switch via pipe: 10509 (9863 - 18761) Time for one Copy-on-Write fault: 71796 (20625 - 207750) Time to exec client once: 1076218 (1066203 - 1085937) Time for one fork/exit/wait: 1193125 (574750 - 1197750) Time

When Zach Amsden added PARAVIRT_LAZY_FLUSH I didn't realize how often it would get called. We only need to do something if we're actually in lazy mode. Before: Time for one context switch via pipe: 10509 (9863 - 18761) Time for one Copy-on-Write fault: 71796 (20625 - 207750) Time to exec client once: 1076218 (1066203 - 1085937) Time for one fork/exit/wait: 1193125 (574750 - 1197750) Time

The VMI ROM has a mode where hypercalls can be queued and batched. This turns out to be a significant win during context switch, but must be done at a specific point before side effects to CPU state are visible to subsequent instructions. This is similar to the MMU batching hooks already provided. The same hooks could be used by the Xen backend to implement a context switch multicall. To

The VMI ROM has a mode where hypercalls can be queued and batched. This turns out to be a significant win during context switch, but must be done at a specific point before side effects to CPU state are visible to subsequent instructions. This is similar to the MMU batching hooks already provided. The same hooks could be used by the Xen backend to implement a context switch multicall. To

The VMI ROM has a mode where hypercalls can be queued and batched. This turns out to be a significant win during context switch, but must be done at a specific point before side effects to CPU state are visible to subsequent instructions. This is similar to the MMU batching hooks already provided. The same hooks could be used by the Xen backend to implement a context switch multicall. To

The VMI ROM has a mode where hypercalls can be queued and batched. This turns out to be a significant win during context switch, but must be done at a specific point before side effects to CPU state are visible to subsequent instructions. This is similar to the MMU batching hooks already provided. The same hooks could be used by the Xen backend to implement a context switch multicall. To

From: Rusty Russell <rusty@rustcorp.com.au> lguest is a simple hypervisor for Linux on Linux. Unlike kvm it doesn't need VT/SVM hardware. Unlike Xen it's simply "modprobe and go". Unlike both, it's 5000 lines and self-contained. Performance is ok, but not great (-30% on kernel compile). But given its hackability, I expect this to improve, along with the