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