search for: vmicalls

Displaying 20 results from an estimated 29 matches for "vmicalls".

Did you mean: vmicall
2007 Apr 18
4
[RFC, PATCH 1/24] i386 Vmi documentation
Index: linux-2.6.16-rc5/Documentation/vmi_spec.txt =================================================================== --- linux-2.6.16-rc5.orig/Documentation/vmi_spec.txt 2006-03-09 23:33:29.000000000 -0800 +++ linux-2.6.16-rc5/Documentation/vmi_spec.txt 2006-03-10 12:55:29.000000000 -0800 @@ -0,0 +1,2197 @@ + + Paravirtualization API Version 2.0 + + Zachary Amsden, Daniel Arai, Daniel Hecht,
2007 Apr 18
4
[RFC, PATCH 1/24] i386 Vmi documentation
Index: linux-2.6.16-rc5/Documentation/vmi_spec.txt =================================================================== --- linux-2.6.16-rc5.orig/Documentation/vmi_spec.txt 2006-03-09 23:33:29.000000000 -0800 +++ linux-2.6.16-rc5/Documentation/vmi_spec.txt 2006-03-10 12:55:29.000000000 -0800 @@ -0,0 +1,2197 @@ + + Paravirtualization API Version 2.0 + + Zachary Amsden, Daniel Arai, Daniel Hecht,
2007 Apr 18
3
[RFC, PATCH 4/24] i386 Vmi inline implementation
...ve_start; \ + native; \ + vmi_native_finish; \ + \ + vmi_translation_start; \ + vmi_call(name); \ + vmi_translation_finish; \ + \ + vmi_padded_start; \ + native; \ + vmi_nop_pad; \ + vmi_padded_finish; \ + \ + vmi_annotate(name); + +#include <vmiCalls.h> +#ifdef __ASSEMBLY__ +/* + * Create VMI_CALL_FuncName definitions for assembly code using + * equates; the C enumerations can not be used without propagating + * them in some fashion, and rather the obfuscate asm-offsets.c, it + * seems reasonable to confine this here. + */ +.equ VMI_CALL_CUR...
2007 Apr 18
3
[RFC, PATCH 4/24] i386 Vmi inline implementation
...ve_start; \ + native; \ + vmi_native_finish; \ + \ + vmi_translation_start; \ + vmi_call(name); \ + vmi_translation_finish; \ + \ + vmi_padded_start; \ + native; \ + vmi_nop_pad; \ + vmi_padded_finish; \ + \ + vmi_annotate(name); + +#include <vmiCalls.h> +#ifdef __ASSEMBLY__ +/* + * Create VMI_CALL_FuncName definitions for assembly code using + * equates; the C enumerations can not be used without propagating + * them in some fashion, and rather the obfuscate asm-offsets.c, it + * seems reasonable to confine this here. + */ +.equ VMI_CALL_CUR...
2007 Apr 18
4
[RFC, PATCH 3/24] i386 Vmi interface definition
...+/* + * paravirtualInterface.h -- + * + * Header file for paravirtualization interface and definitions + * for the hypervisor option ROM tables. + * + * Copyright (C) 2005, VMWare, Inc. + * + */ + +#ifndef _PARAVIRTUAL_INTERFACE_H_ +#define _PARAVIRTUAL_INTERFACE_H_ + +#include "vmiCalls.h" + +/* + *--------------------------------------------------------------------- + * + * VMI Option ROM API + * + *--------------------------------------------------------------------- + */ +#define VDEF(call) VMI_CALL_##call, +typedef enum VMICall { + VMI_CALLS + NUM_VMI_CALLS +} VMICal...
2007 Apr 18
4
[RFC, PATCH 3/24] i386 Vmi interface definition
...+/* + * paravirtualInterface.h -- + * + * Header file for paravirtualization interface and definitions + * for the hypervisor option ROM tables. + * + * Copyright (C) 2005, VMWare, Inc. + * + */ + +#ifndef _PARAVIRTUAL_INTERFACE_H_ +#define _PARAVIRTUAL_INTERFACE_H_ + +#include "vmiCalls.h" + +/* + *--------------------------------------------------------------------- + * + * VMI Option ROM API + * + *--------------------------------------------------------------------- + */ +#define VDEF(call) VMI_CALL_##call, +typedef enum VMICall { + VMI_CALLS + NUM_VMI_CALLS +} VMICal...
2007 Apr 18
7
[RFC, PATCH 5/24] i386 Vmi code patching
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
2007 Apr 18
7
[RFC, PATCH 5/24] i386 Vmi code patching
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
2007 Apr 18
0
[PATCH 8/9] Vmi apic ops.diff
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
2007 Apr 18
0
[PATCH 8/9] Vmi apic ops.diff
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
2007 Apr 18
1
[PATCH] 2.6.21 - VMI logic error
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
2007 Apr 18
1
[PATCH] 2.6.21 - VMI logic error
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
2010 Aug 23
1
Removing VMI kernel support from 2.6.37
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
2010 Aug 23
1
Removing VMI kernel support from 2.6.37
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
2007 Apr 18
0
[PATCH 4/5] Vmi.patch
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
2007 Apr 18
0
[PATCH 4/5] Vmi.patch
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
2007 Apr 18
0
[PATCH 5/6] VMI backend for paravirt-ops
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
2007 Apr 18
0
[PATCH 5/6] VMI backend for paravirt-ops
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
2007 Apr 18
0
[RFC, PATCH 6/24] i386 Vmi magic fixes
...lic License for more + * details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Send feedback to zach@vmware.com + * + */ + +#include <vmiCalls.h> + +#define VDEF(name) \ + . = __VMI_NEXT; \ + __VMI_NEXT = . + 32; \ + *(.text.VMI_##name); + +#define MACH_TEXT \ +. = ALIGN(4096); \ +__VMI_START = .; \ +__VMI_NEXT = .; \ +__VMI_END = . + 16384; \ +VMI_CALLS \ +. = __VMI_END; \ +. = ALIGN(4096); Index: linux-2.6.16-rc3/include/asm-i3...
2007 Apr 18
0
[RFC, PATCH 6/24] i386 Vmi magic fixes
...lic License for more + * details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Send feedback to zach@vmware.com + * + */ + +#include <vmiCalls.h> + +#define VDEF(name) \ + . = __VMI_NEXT; \ + __VMI_NEXT = . + 32; \ + *(.text.VMI_##name); + +#define MACH_TEXT \ +. = ALIGN(4096); \ +__VMI_START = .; \ +__VMI_NEXT = .; \ +__VMI_END = . + 16384; \ +VMI_CALLS \ +. = __VMI_END; \ +. = ALIGN(4096); Index: linux-2.6.16-rc3/include/asm-i3...