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.
>>>
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 k
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 sp
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
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
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
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 h
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 stable
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);
>> +}
>> +
>> +st
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 kvm_xinter
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 ver
> 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 because xinterface.o is
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 fin
13 matches
Mail list logo
