similar to: [RFC, PATCH 21/24] i386 Vmi proc node

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

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance significantly. However, when

VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance significantly. However, when

Fairly straightforward implementation of VMI backend for paravirt-ops. Subject: VMI backend for paravirt-ops Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance

Fairly straightforward implementation of VMI backend for paravirt-ops. Subject: VMI backend for paravirt-ops Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance

A NO_IDLE_HZ implementation is provided for i386 VMI builds. When a VCPU enters its idle loop, it disables its periodic alarm and sets up a one shot alarm for the next time event. That way, it does not become ready to run just to service the periodic alarm interrupt. Instead, it can remain halted until there is some real work pending for it. This allows the hypervisor to use the physical

A NO_IDLE_HZ implementation is provided for i386 VMI builds. When a VCPU enters its idle loop, it disables its periodic alarm and sets up a one shot alarm for the next time event. That way, it does not become ready to run just to service the periodic alarm interrupt. Instead, it can remain halted until there is some real work pending for it. This allows the hypervisor to use the physical

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

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

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

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

In paravirt builds with VMI compiled in, vmi_bringup is called unconditionally, not via a paravirt-ops table (as no other hypervisor uses the APIC startup technique). Make the calls to setup VMI state conditional on the presence of the VMI ROM. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1915e2685a3c arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Jan 04 15:56:40 2007

In paravirt builds with VMI compiled in, vmi_bringup is called unconditionally, not via a paravirt-ops table (as no other hypervisor uses the APIC startup technique). Make the calls to setup VMI state conditional on the presence of the VMI ROM. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1915e2685a3c arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Jan 04 15:56:40 2007

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

Not respecting udelay causes problems with any virtual hardware that is passed through to real hardware. This can be noticed by any device that interacts with the real world in real time - like AP startup, which takes real time. Or keyboard LEDs, which should blink in real-time. Or floppy drives, but only when passed through to a real floppy controller on OSes which can't sufficiently

Not respecting udelay causes problems with any virtual hardware that is passed through to real hardware. This can be noticed by any device that interacts with the real world in real time - like AP startup, which takes real time. Or keyboard LEDs, which should blink in real-time. Or floppy drives, but only when passed through to a real floppy controller on OSes which can't sufficiently