lkml.org 
[lkml]   [2011]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/16] KVM-HDR: register KVM basic header infrastructure
On 01/24/2011 08:06 PM, Glauber Costa wrote:
> KVM, which stands for KVM Virtual Memory (I wanted to call it KVM Virtual Mojito),
> is a piece of shared memory that is visible to both the hypervisor and the guest
> kernel - but not the guest userspace.
>
> The basic idea is that the guest can tell the hypervisor about a specific
> piece of memory, and what it expects to find in there. This is a generic
> abstraction, that goes to userspace (qemu) if KVM (the hypervisor) can't
> handle a specific request, thus giving us flexibility in some features
> in the future.
>
> KVM (The hypervisor) can change the contents of this piece of memory at
> will. This works well with paravirtual information, and hopefully
> normal guest memory - like last update time for the watchdog, for
> instance.
>
> This is basic KVM registration headers. I am keeping headers
> separate to facilitate backports to people who wants to backport
> the kernel part but not the hypervisor, or the other way around.
>
> Signed-off-by: Glauber Costa<glommer@redhat.com>
> CC: Avi Kivity<avi@redhat.com>
> ---
> arch/x86/include/asm/kvm_para.h | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index a427bf7..b0b0ee0 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -21,6 +21,7 @@
> */
> #define KVM_FEATURE_CLOCKSOURCE2 3
> #define KVM_FEATURE_ASYNC_PF 4
> +#define KVM_FEATURE_MEMORY_AREA 5
>
> /* The last 8 bits are used to indicate how to interpret the flags field
> * in pvclock structure. If no bits are set, all flags are ignored.
> @@ -35,6 +36,16 @@
> #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> #define MSR_KVM_ASYNC_PF_EN 0x4b564d02
>
> +#define MSR_KVM_REGISTER_MEM_AREA 0x4b564d03
> +
> +struct kvm_memory_area {
> + __u64 base;
> + __u32 size;
> + __u32 type;
> + __u8 result;
> + __u8 pad[3];
> +};
> +
> #define KVM_MAX_MMU_OP_BATCH 32

I'm guessing the protocol here is:

- guest fills in ->base/size/type
- issues wrmsr
- host registers the memory and updates ->result
- guest examines ->result

there are two issues with this approach:

- it doesn't lend itself will to live migration. Extra state must be
maintained in the hypervisor.
- it isn't how normal hardware operates

what's wrong with extending the normal approach of one msr per feature?

--
error compiling committee.c: too many arguments to function



\
 
 \ /
  Last update: 2011-01-26 12:09    [W:0.742 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site