What: xinterface is a mechanism that allows kernel modules external to
the kvm.ko proper to interface with a running guest. It accomplishes
this by creating an abstracted interface which does not expose any
private details of the guest or its related KVM structures, and provides
a mechanism to
Sam Ravnborg wrote:
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index ad8ec35..9f50cc3 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -1,5 +1,7 @@
-obj-$(CONFIG_KVM) += kvm/
+ifdef CONFIG_KVM
+obj-y += kvm/
+endif
What was wrong with the old version?
If this is
Gregory Haskins wrote:
+/*
+ *
+ * XINTERFACE (External Interface)
+ * -
+ */
+
+static struct kvm *
+intf_to_kvm(struct kvm_xinterface *intf)
+{
+ return container_of(intf, struct kvm, xinterface);
+}
+
+static unsigned long
+xinterface_gpa_to_hva(struct
Anthony Liguori wrote:
Gregory Haskins wrote:
+/*
+ *
+ * XINTERFACE (External Interface)
+ * -
+ */
+
+static struct kvm *
+intf_to_kvm(struct kvm_xinterface *intf)
+{
+return container_of(intf, struct kvm, xinterface);
+}
+
+static unsigned long
Gregory Haskins wrote:
That said, I think the assumption that was made when I was using this
was that a proper ref for the page was acquired by the gfn_to_page() and
dropped by the caller. This was always used in the context of a
hypercall/vmexit so presumably the gpa should be considered
On Thursday 16 July 2009, Gregory Haskins wrote:
Background: The original vbus code was tightly integrated with kvm.ko. Avi
suggested that we abstract the interfaces such that it could live outside
of kvm.
The code is still highly kvm-specific, you would not be able to use
it with another
Arnd Bergmann wrote:
On Thursday 16 July 2009, Gregory Haskins wrote:
Background: The original vbus code was tightly integrated with kvm.ko. Avi
suggested that we abstract the interfaces such that it could live outside
of kvm.
The code is still highly kvm-specific, you would not
Gregory Haskins wrote:
Note that if we are going to generalize the interface to support other
guests as you may have been suggesting above, it should probably stay
statically linked (and perhaps live in ./lib or something)
More specifically, it can no longer live in kvm.ko. I guess it
On Thursday 16 July 2009, Gregory Haskins wrote:
Arnd Bergmann wrote:
Your approach allows passing the vmid from a process that does
not own the kvm context. This looks like an intentional feature,
but I can't see what this gains us.
This work is towards the implementation of
Zan Lynx wrote:
Gregory Haskins wrote:
Gregory Haskins wrote:
Note that if we are going to generalize the interface to support other
guests as you may have been suggesting above, it should probably stay
statically linked (and perhaps live in ./lib or something)
More specifically, it can
Gregory Haskins wrote:
Gregory Haskins wrote:
Note that if we are going to generalize the interface to support other
guests as you may have been suggesting above, it should probably stay
statically linked (and perhaps live in ./lib or something)
More specifically, it can no longer live in
Arnd Bergmann wrote:
On Thursday 16 July 2009, Gregory Haskins wrote:
Arnd Bergmann wrote:
Your approach allows passing the vmid from a process that does
not own the kvm context. This looks like an intentional feature,
but I can't see what this gains us.
This work is
12 matches
Mail list logo
