Move per VCPU mmu_memory_cache to be VM basis.
Your opnion?
Eddie
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..77989b4 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -300,11 +300,6 @@ struct kvm_vcpu {
struct kvm_mmu mmu;
- struct
Rusty Russell wrote:
Two versions, size *and* ret? This seems like overkill...
I think we ought to move away from version numbers and use feature
availability flags instead.
+ if (rc) {
+ printk(KERN_INFO paravirt KVM unavailable\n);
Double-printk when KVM
Anthony Liguori wrote:
For KVM, it should be okay as well. But we can replace two CR4 accesses
with just one hypercall.
I was thinking the same thing :-)
I was actually thinking about adding a hypercall to set/clear a bit in a
control register. The thought here is
Dong, Eddie wrote:
Move per VCPU mmu_memory_cache to be VM basis.
Your opnion?
Eddie
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..77989b4 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -300,11 +300,6 @@ struct kvm_vcpu {
struct kvm_mmu mmu;
Avi Kivity wrote:
Dong, Eddie wrote:
Move per VCPU mmu_memory_cache to be VM basis.
Your opnion?
Eddie
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..77989b4 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -300,11 +300,6 @@ struct kvm_vcpu {
Hello,
Looking at kvm-26, it seems that the CPUID values as seen by the guest OS
are still hardcoded for i386/x86-64 at least.
For performance counter virtualization, the guest needs to see the *actual*
family/model information in order to correctly program the counters.
It would be fairly
Avi Kivity wrote:
Anthony Liguori wrote:
For KVM, it should be okay as well. But we can replace two CR4 accesses
with just one hypercall.
I was thinking the same thing :-)
I was actually thinking about adding a hypercall to set/clear a bit
in a control register. The
Stephane Eranian wrote:
Hello,
Looking at kvm-26, it seems that the CPUID values as seen by the guest OS
are still hardcoded for i386/x86-64 at least.
For performance counter virtualization, the guest needs to see the *actual*
family/model information in order to correctly program the
On Thursday 31 May 2007 12:11:16 Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
+ if (wrmsr_safe(MSR_KVM_API_MAGIC, __pa(para_state), 0)) {
+ printk(KERN_INFO KVM guest: WRMSR probe failed.\n);
+ return -ENOENT;
+ }
Stephane Eranian wrote:
The main issue is migration (and save/restore). If you migrate to a
host with fewer capabilities, applications may fail when they use
unavailable instructions that they successfully detected earlier.
In the case of heterogeneous migration, clearly performance
Avi,
On Thu, May 31, 2007 at 02:35:44PM +0300, Avi Kivity wrote:
In the case of heterogeneous migration, clearly performance counters
will not work well, especially for unmodified guests.
Right.
But I can also
see problems when migrating from Intel Core to older P4 for
Avi,
On Thu, May 31, 2007 at 02:52:05PM +0300, Avi Kivity wrote:
Stephane Eranian wrote:
If the guest cpuid is set to a least common denominator, it should work.
There is no common denominator between a P4 and Intel Core 2 Duo for the
performance counters. So you cannot simply use a
Example net driver using virtio
TODO:
1) Locking (see #2).
2) NAPI.
3) GSO.
4) Checksum options.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
drivers/net/Makefile |2
drivers/net/virtio_net.c | 237
This attempts to implement a virtual I/O layer which should allow
common drivers to be efficiently used across most virtual I/O
mechanisms. It will no-doubt need further enhancement.
The details of probing the device are left to hypervisor-specific
code: it simple constructs the struct
On 5/31/07, Troy Benjegerdes [EMAIL PROTECTED] wrote:
The only halfway sane solution I can think of involves having guest
support for CPU hotplug, so that a host can notify a guest that the
underlying CPU has changed.
well, but ... if the migration has happened, and some app is reading
the
Troy Benjegerdes wrote:
This kind of a claim needs some benchmark data to document it.
We've implemented both for our vdisk driver on 390. At least on our
platform, merging in the host is preferable because vmenter/vmexit is
very fast and we would merge twice because we submit the result via
Rusty Russell wrote:
On Thu, 2007-05-31 at 12:40 +0200, Andi Kleen wrote:
On Thursday 31 May 2007 12:11:16 Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
+ if (wrmsr_safe(MSR_KVM_API_MAGIC, __pa(para_state), 0)) {
+ printk(KERN_INFO KVM guest:
Andi Kleen wrote:
On Thursday 31 May 2007 12:11:16 Ingo Molnar wrote:
yeah. I suspect printing that it's executing in native mode is OK.
But only a single printk for that please
This will be taken care of in the next round of patches.
Regards,
Anthony Liguori
-Andi
Nakajima, Jun wrote:
Anthony Liguori wrote:
Nakajima, Jun wrote:
Anthony Liguori wrote:
Regards,
Anthony Liguori
I think we should use the CPUID instruction (leaf 0x4000) to
detect
the hypervosor as we are doing in Xen.
Is that leaf
Incorporates v8 plus the following changes:
1) Fix for hang on AMD
2) Fixes issue where irq-windows are inaccurately reported to userspace
3) Fixed issue where irq-window-exiting requests can be ignored in some cases
Note that we no longer need the backlog.patch to handle a corner cases now.
As
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 60 +++
drivers/kvm/kvm_main.c | 94 ++--
2 files changed, 142 insertions(+), 12 deletions(-)
diff --git a/drivers/kvm/kvm.h
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
drivers/kvm/Makefile |2
drivers/kvm/kernint.c | 149 +
drivers/kvm/kvm.h | 35 +
drivers/kvm/kvm_main.c | 198 ++-
drivers/kvm/lapic.c| 1418
drivers/kvm/svm.c
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
drivers/kvm/kvm.h |6 ++
drivers/kvm/kvm_main.c | 23 ---
drivers/kvm/svm.c |2 ++
drivers/kvm/vmx.c |2 ++
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/kvm/kvm.h
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/Kbuild |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/Kbuild b/kernel/Kbuild
index e9bcda7..103a179 100644
--- a/kernel/Kbuild
+++ b/kernel/Kbuild
@@ -1,5 +1,5 @@
EXTRA_CFLAGS := -I$(src)/include
Non-performance critical code is made more awkward by having to always define
both #ifdef KVM and if (kvm_allowed). Define kvm_allowed = 0 by
default. Anthony Ligouri is credited with the idea.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
qemu/qemu-kvm.c |9 -
1 files
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 27 +++
qemu/qemu-kvm.h |5 +
qemu/vl.c | 10 ++
qemu/vl.h |1 +
4 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
qemu/hw/apic.c | 25 +
qemu/hw/pc.c| 35 ---
qemu/qemu-kvm.c | 53 +++--
qemu/qemu-kvm.h |3 +++
qemu/vl.h | 15
Anthony Liguori wrote:
Nakajima, Jun wrote:
What I can say is that we (including the H/W teams) reviewed it
internally.
I've switched to using CPUID. I noticed that Xen also uses
0x40001
so I'm presuming that that is okay too?
Yes.
Regards,
Anthony Liguori
Jun
---
Intel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Eranian wrote:
They use cpuid. I expect more and more applications/OS will rely on
performance counters to boost performance at runtime.
That's a definitive fact. ld.so for the longest time selects special
DSOs to load automatically based
On Thu, 2007-05-31 at 14:57 +0200, Carsten Otte wrote:
Rusty Russell wrote:
Example block driver using virtio.
The block driver uses outbufs with sg[0] being the request information
(struct virtio_blk_outhdr) with the type, sector and inbuf id. For a
write, the rest of the sg will
Axel Kittenberger wrote:
Unfortunally all machines detect the same ethernet address
'52:54:00:12:34:56'. Which you can guess what i means, networking comes
and goes whatever machine last the ethernet address got hold of from the
gateway. I tried specifing an ethernet-adress with -net
Ulrich Drepper wrote:
Stephane Eranian wrote:
They use cpuid. I expect more and more applications/OS will rely on
performance counters to boost performance at runtime.
That's a definitive fact. ld.so for the longest time selects special
DSOs to load automatically based on the data. String
I don't think this patch is complete to add NMIP support to KVM, and can
you pls exclude it from current APIC patchsets? We can revisit it later
with more thoughts.
-Xin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Gregory Haskins
Sent: Friday,
On Thu, May 31, 2007 at 10:43 PM, in message
[EMAIL PROTECTED], Li,
Xin B [EMAIL PROTECTED] wrote:
I don't think this patch is complete to add NMIP support to KVM
Could you be more specific on whats left to be done? From what I could read in
the doc, this seemed complete.
and can you pls
I don't think this patch is complete to add NMIP support to KVM
Could you be more specific on whats left to be done? From
what I could read in the doc, this seemed complete.
This is a good start, and we also need to add a vmexit handler to handle
exit reason 8, NMI pending.
And the major
I met an error when i build latest KVM on rhel5.
Seems asm/cmpxchg.h is not in the kernel before 2.6.22.
How can I fix the issue?
make -C kernel
make[1]: Entering directory `/tmp/tmp/kvm-userspace/kernel'
make -C /lib/modules/2.6.18-8.el5/build M=`pwd` $@
make[2]: Entering directory
36 matches
Mail list logo
