I've tried out the last few versions of KVM and think it's great. It's
much easier to use and understand than Xen and performance is
surprisingly good.
One of the things I'd like to do is modify it to allow PMI generation
based on the Intel performance counter facilities. Specifically, I'd
like to
On Tue, 2007-01-09 at 16:27 +0200, Avi Kivity wrote:
> Hugo Mills wrote:
> >Does running paravirtual guests on KVM still require a
> > hardware-VM-capable processor, or will it eventually be possible to
> > run a paravirtualised Linux on an older machine (such as, say, a
> > first-generation At
Roland Dreier wrote:
I'm running a 64-bit Fedora 6 install as a guest on a host running
2.6.20-rc4 with the kvm-10 userspace release. The CPU is a Xeon 5160
and I have 6 GB of RAM. The guest is given 512 MB of memory. I left
the guest idle overnight, and the makewhatis cron job seems to have
t
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i've updated the cr3-cache code to use the new hypercall facility -
> this solves the hpa/gpa aliasing bug you found.
>
> i have changed a few more details around hypercalls - the macros are
> now cleaner, the cr3 cache is aligned (is easier to grow b
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok. Below is the current snapshot - hypercall calling convention
> documented and implemented for both 64-bit and 32-bit on the KVM side,
> and a small demo call done on the 32-bit guest side.
i've updated the cr3-cache code to use the new hypercall f
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > about the 32-bit side: maybe it gives us a bit more options for
> > later if we pick the natural order for 32-bit too: EBX for index,
> > EAX, EDX, ECX for the first 3 parameters, with the remaining 3
> > parameters in ESI, EDI, EBP? Most hypercalls
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
>> +/*
>> + * Hypercall calling convention:
>> + *
>> + * RAX is the hypercall index, goes from 0 to __NR_hypercalls-1
>> + *
>> + * Each hypercall may have 0-6 parameters.
>> + *
>> + * parameters 1-6 are in the standard gcc x86_
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> +/*
> + * Hypercall calling convention:
> + *
> + * RAX is the hypercall index, goes from 0 to __NR_hypercalls-1
> + *
> + * Each hypercall may have 0-6 parameters.
> + *
> + * parameters 1-6 are in the standard gcc x86_64 calling convention
> + * order:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > so i'd vote for the 64-bit natural register order: return value in
> > rax, parameters in: rdi, rsi, rdx, rcx, r8, r9. On 32-bit that would
> > be edi, esi, edx, ecx, ebx, ebp - the last two shuffled into
> > VCPU_REGS_R8/R9. That's 6 parameters alre
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> well, we can standardize on the 32-bit calling convention: eax, ecx,
>>> edx, ebp, etc. We can do that via the 64-bit asm. So it should be the
>>> same i think - just that a 32-bit guest on a 64-bit host wont be able
>>> to
Hugo Mills wrote:
>I'm a little unclear on the capabilities (current or planned) of
> the new paravirtualisation feature in KVM.
>
>Does running paravirtual guests on KVM still require a
> hardware-VM-capable processor, or will it eventually be possible to
> run a paravirtualised Linux on a
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >well, we can standardize on the 32-bit calling convention: eax, ecx,
> >edx, ebp, etc. We can do that via the 64-bit asm. So it should be the
> >same i think - just that a 32-bit guest on a 64-bit host wont be able
> >to set the high bits of those reg
I'm a little unclear on the capabilities (current or planned) of
the new paravirtualisation feature in KVM.
Does running paravirtual guests on KVM still require a
hardware-VM-capable processor, or will it eventually be possible to
run a paravirtualised Linux on an older machine (such as, say
Jeff Garzik wrote:
> Can we please avoid adding a ton of new ioctls? ioctls inevitably
> require 64-bit compat code for certain architectures, whereas
> sysfs/procfs does not.
>
I don't see how the procfs or sysfs models fit kvm. wrt compat code,
the current kvm abi (also ioctl based) is 32/6
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> Does this look good to you? I'd like the basic API to be as light as
>>> possible.
>>>
>> Won't 32-bit and 64-bit pick different registers?
>>
>> We can work around it (call is_long_mode() when decoding the
>> hypercal
On Tue, 9 Jan 2007, Jeff Garzik wrote:
> Can we please avoid adding a ton of new ioctls? ioctls inevitably
> require 64-bit compat code for certain architectures, whereas
> sysfs/procfs does not.
I guess ioctl is not as important now if the API is now always talking to
one VM.
- James
--
J
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Does this look good to you? I'd like the basic API to be as light as
> > possible.
>
> Won't 32-bit and 64-bit pick different registers?
>
> We can work around it (call is_long_mode() when decoding the
> hypercall), but it kind of defeats the purpos
Can we please avoid adding a ton of new ioctls? ioctls inevitably
require 64-bit compat code for certain architectures, whereas
sysfs/procfs does not.
Jeff
-
Take Surveys. Earn Cash. Influence the Future of IT
J
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
Where is the vmcall exit handler?
>>> in my tree, have not sent the patch yet - first want to combine it
>>> with the cr3 feature to have it tested.
>>>
>>>
>> I'd like it in the final patch.
>
I had originally hoped to get this in for 2.6.20. It now looks like .20
will have a shorter cycle than usual, and the mmu took a bit longer than
expected, so it's more realistic to aim for 2.6.21.
The current kvm userspace interface has several deficiencies:
- open("/dev/kvm") returns a differ
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> NOTE: i have not updated the cr3 patch to the hypercall API yet (hence
> the aliasing bug is not fixed yet), i wanted to get this to you so
> that we can think about the hypercall API.
>
> Right now what i have is only good to test that the VMCALL ins
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >>Where is the vmcall exit handler?
> >>
> >
> >in my tree, have not sent the patch yet - first want to combine it
> >with the cr3 feature to have it tested.
> >
>
> I'd like it in the final patch.
yeah. Right now i have:
patches/kvm-paravirt-h
Ingo Molnar wrote:
> ok, i changed this and i added the SVM patch function too. AMD's VMMCALL
> is 0x0f, 0x01, 0xd9, correct?
>
>
yes.
>> Where is the vmcall exit handler?
>>
>
> in my tree, have not sent the patch yet - first want to combine it with
> the cr3 feature to have it tested.
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >>>+struct kvm_cr3_cache {
> >>>+ struct kvm_cr3_cache_entry entry[KVM_CR3_CACHE_SIZE];
> >>>+ u32 max_idx;
> >>>+};
> >>>
> >>>
> >>This will require an api version bump whenever KVM_CR3_CACHE_SIZE
> >>changes.
> >>
> >>Better to advertise the
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> @@ -237,6 +238,8 @@ struct kvm_vcpu {
>>> unsigned long cr0;
>>> unsigned long cr2;
>>> unsigned long cr3;
>>> + struct kvm_vcpu_para_state *para_state;
>>>
>>>
>> Do we want this as part of kvm_vcpu or k
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> There's a problem here. A cache-hit cr3 is an hpa, while a cache-miss
> cr3 is a gpa. The two could alias:
ok, agreed. This is nice in fact, because this will be a live test of
the hypercall API :-)
> The only solution I see is to use the hypercall
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >@@ -237,6 +238,8 @@ struct kvm_vcpu {
> > unsigned long cr0;
> > unsigned long cr2;
> > unsigned long cr3;
> >+struct kvm_vcpu_para_state *para_state;
> >
> Do we want this as part of kvm_vcpu or kvm? I can see arguments for
> both vi
Ingo Molnar wrote:
> Subject: [patch] KVM: paravirtual guest support
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> this enables a CONFIG_PARAVIRT Linux guest kernel to establish a
> hypercall API to a KVM host. If successfully registered, then the Linux
> guest will optimize a few things like its i
Ingo Molnar wrote:
> Subject: [patch] KVM: add MSR based hypercall API
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> this adds a special MSR based hypercall API to KVM. This is to be used
> by paravirtual kernels and virtual drivers.
>
> VMX-only at the moment.
>
> Signed-off-by: Ingo Molnar <[EMAIL
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Subject: [patch] KVM: paravirtual guest support
> From: Ingo Molnar <[EMAIL PROTECTED]>
also needs this patch.
Ingo
Index: linux/include/asm-i386/processor.h
===
--- linux.orig/in
Subject: [patch] KVM: cr3 cache support
From: Ingo Molnar <[EMAIL PROTECTED]>
this enables a KVM-aware Linux guest to make use of VMX CPU's cr3 cache
feature. The result is cheaper context-switches and faster TLB flushes.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h
Subject: [patch] KVM: paravirtual guest support
From: Ingo Molnar <[EMAIL PROTECTED]>
this enables a CONFIG_PARAVIRT Linux guest kernel to establish a
hypercall API to a KVM host. If successfully registered, then the Linux
guest will optimize a few things like its interrupt controller, io-delay
Subject: [patch] KVM: add MSR based hypercall API
From: Ingo Molnar <[EMAIL PROTECTED]>
this adds a special MSR based hypercall API to KVM. This is to be used
by paravirtual kernels and virtual drivers.
VMX-only at the moment.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.
Bugs item #1631252, was opened at 2007-01-09 09:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1631252&group_id=180599
Please note that this message will contain a full copy
Roland Dreier wrote:
> I'm running a 64-bit Fedora 6 install as a guest on a host running
> 2.6.20-rc4 with the kvm-10 userspace release. The CPU is a Xeon 5160
> and I have 6 GB of RAM. The guest is given 512 MB of memory. I left
> the guest idle overnight, and the makewhatis cron job seems to
35 matches
Mail list logo
