similar to: [PATCH] Fix lazy mode vmalloc synchronization for paravirt

I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous

I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous

In general, I/O in a virtual guest is subject to performance problems. = The I/O can not be completed physically, but must be virtualized. This = means trapping and decoding port I/O instructions from the guest OS. = Not only is the trap for a #GP heavyweight, both in the processor and = the hypervisor (which usually has a complex #GP path), but this forces = the hypervisor to decode the

In general, I/O in a virtual guest is subject to performance problems. = The I/O can not be completed physically, but must be virtualized. This = means trapping and decoding port I/O instructions from the guest OS. = Not only is the trap for a #GP heavyweight, both in the processor and = the hypervisor (which usually has a complex #GP path), but this forces = the hypervisor to decode the

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 complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions,

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 complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions,

I''m sure everyone has seen the drop of VMI patches for Linux at this point, but just in case, the link is included below. I''ve read this version of the VMI spec and have made my way through most of the patches. While I wasn''t really that impressed with the first spec wrt Xen, the second version seems to be much more palatable. Specifically, the code inlining and

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

[ 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

Seems to work OK for native and Xen. I had to play a bit with the paravirt-sched-clock patch to deal with the VMI changes. Zach, can you check that it still works? Thanks, J

Seems to work OK for native and Xen. I had to play a bit with the paravirt-sched-clock patch to deal with the VMI changes. Zach, can you check that it still works? Thanks, J

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

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

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

The VMI ROM detection and code patching mechanism is illustrated in setup.c. There ROM is a binary block published by the hypervisor, and and there are certainly implications of this. ROMs certainly have a history of being proprietary, very differently licensed pieces of software, and mostly under non-free licenses. Before jumping to the conclusion that this is a bad thing, let us consider more

The VMI ROM detection and code patching mechanism is illustrated in setup.c. There ROM is a binary block published by the hypervisor, and and there are certainly implications of this. ROMs certainly have a history of being proprietary, very differently licensed pieces of software, and mostly under non-free licenses. Before jumping to the conclusion that this is a bad thing, let us consider more

Macros to use VMI calls from assembly and C languages are introduced. The macros are quite complex, but the end result is rather impressive. The result is that when compiling a VMI kernel, the native code is emitted inline, with no function call overhead, and some wiggle room for register allocation. The hypervisor compatibility code is emitted out of line into a separate section, and patched