[PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
The default action of calesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No need for input or accessing other devices frequently.
This issue was observed in a experimental embbed system. The test image simply
print test every 1 seconds. The output in QEmu meets expectation, but the
output in KVM is delayed for seconds.
To solve this issue, a timeout is added, to ensure userspace exit freqency is
high enough(mostly target for video now) to write the buffered MMIO data.
Current the maximum exit interval is 1/25s(so 25 times exit to userspace per
second at least, pretty low compared to normal environment), and reused
KVM_EXIT_IRQ_WINDOW_OPEN as exit reason, for it would doing nothing at all in
userspace handler.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/x86.c | 31 +++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a1f0b5d..eb8bb20 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -365,6 +365,8 @@ struct kvm_vcpu_arch {
unsigned long singlestep_rip;
/* fields used by HYPER-V emulation */
u64 hv_vapic;
+
+ ktime_t latest_userspace_exit_time;
};
struct kvm_mem_alias {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 56a90a6..0b05f11 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4339,6 +4339,20 @@ out:
return r;
}
+#ifdef CONFIG_KVM_MMIO
+
+#define KVM_USERSPACE_MMIO_MAX_INTERVAL (NSEC_PER_SEC / 25)
+static bool mmio_need_exit_to_userspace(struct kvm_vcpu *vcpu)
+{
+ ktime_t gap, now = ktime_get();
+
+ gap = ktime_sub(now, vcpu-arch.latest_userspace_exit_time);
+ if (ktime_to_ns(gap) KVM_USERSPACE_MMIO_MAX_INTERVAL)
+ return true;
+
+ return false;
+}
+#endif
static int __vcpu_run(struct kvm_vcpu *vcpu)
{
@@ -4404,6 +4418,10 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
kvm_resched(vcpu);
vcpu-srcu_idx = srcu_read_lock(kvm-srcu);
}
+#ifdef CONFIG_KVM_MMIO
+ if (mmio_need_exit_to_userspace(vcpu))
+ r = 0;
+#endif
}
srcu_read_unlock(kvm-srcu, vcpu-srcu_idx);
@@ -4463,6 +4481,16 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
r = __vcpu_run(vcpu);
+#ifdef CONFIG_KVM_MMIO
+ if (mmio_need_exit_to_userspace(vcpu)) {
+ /* Use KVM_EXIT_IRQ_WINDOW_OPEN because userspace would do
+* nothing to handle it */
+ kvm_run-exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN;
+ r = 0;
+ }
+ vcpu-arch.latest_userspace_exit_time = ktime_get();
+#endif
+
out:
if (vcpu-sigset_active)
sigprocmask(SIG_SETMASK, sigsaved, NULL);
@@ -5455,6 +5483,9 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
goto fail_mmu_destroy;
}
vcpu-arch.mcg_cap = KVM_MAX_MCE_BANKS;
+#ifdef CONFIG_KVM_MMIO
+ vcpu-arch.latest_userspace_exit_time = ktime_get();
+#endif
return 0;
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
On Wednesday 20 January 2010 16:35:59 Sheng Yang wrote:
The default action of calesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No need for input or accessing other devices frequently.
No need for exiting to the QEmu in a period should be more precise...
--
regards
Yang, Sheng
This issue was observed in a experimental embbed system. The test image
simply print test every 1 seconds. The output in QEmu meets expectation,
but the output in KVM is delayed for seconds.
To solve this issue, a timeout is added, to ensure userspace exit freqency
is high enough(mostly target for video now) to write the buffered MMIO
data. Current the maximum exit interval is 1/25s(so 25 times exit to
userspace per second at least, pretty low compared to normal environment),
and reused KVM_EXIT_IRQ_WINDOW_OPEN as exit reason, for it would doing
nothing at all in userspace handler.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/x86.c | 31 +++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h index a1f0b5d..eb8bb20 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -365,6 +365,8 @@ struct kvm_vcpu_arch {
unsigned long singlestep_rip;
/* fields used by HYPER-V emulation */
u64 hv_vapic;
+
+ ktime_t latest_userspace_exit_time;
};
struct kvm_mem_alias {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 56a90a6..0b05f11 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4339,6 +4339,20 @@ out:
return r;
}
+#ifdef CONFIG_KVM_MMIO
+
+#define KVM_USERSPACE_MMIO_MAX_INTERVAL (NSEC_PER_SEC / 25)
+static bool mmio_need_exit_to_userspace(struct kvm_vcpu *vcpu)
+{
+ ktime_t gap, now = ktime_get();
+
+ gap = ktime_sub(now, vcpu-arch.latest_userspace_exit_time);
+ if (ktime_to_ns(gap) KVM_USERSPACE_MMIO_MAX_INTERVAL)
+ return true;
+
+ return false;
+}
+#endif
static int __vcpu_run(struct kvm_vcpu *vcpu)
{
@@ -4404,6 +4418,10 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
kvm_resched(vcpu);
vcpu-srcu_idx = srcu_read_lock(kvm-srcu);
}
+#ifdef CONFIG_KVM_MMIO
+ if (mmio_need_exit_to_userspace(vcpu))
+ r = 0;
+#endif
}
srcu_read_unlock(kvm-srcu, vcpu-srcu_idx);
@@ -4463,6 +4481,16 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
r = __vcpu_run(vcpu);
+#ifdef CONFIG_KVM_MMIO
+ if (mmio_need_exit_to_userspace(vcpu)) {
+ /* Use KVM_EXIT_IRQ_WINDOW_OPEN because userspace would do
+ * nothing to handle it */
+ kvm_run-exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN;
+ r = 0;
+ }
+ vcpu-arch.latest_userspace_exit_time = ktime_get();
+#endif
+
out:
if (vcpu-sigset_active)
sigprocmask(SIG_SETMASK, sigsaved, NULL);
@@ -5455,6 +5483,9 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
goto fail_mmu_destroy;
}
vcpu-arch.mcg_cap = KVM_MAX_MCE_BANKS;
+#ifdef CONFIG_KVM_MMIO
+ vcpu-arch.latest_userspace_exit_time = ktime_get();
+#endif
return 0;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
On 01/20/2010 10:35 AM, Sheng Yang wrote: The default action of calesced MMIO is, cache the writing in buffer, until: 1. The buffer is full. 2. Or the exit to QEmu due to other reasons. But this would result in a very late writing in some condition. 1. The each time write to MMIO content is small. 2. The writing interval is big. 3. No need for input or accessing other devices frequently. This issue was observed in a experimental embbed system. The test image simply print test every 1 seconds. The output in QEmu meets expectation, but the output in KVM is delayed for seconds. To solve this issue, a timeout is added, to ensure userspace exit freqency is high enough(mostly target for video now) to write the buffered MMIO data. Current the maximum exit interval is 1/25s(so 25 times exit to userspace per second at least, pretty low compared to normal environment), and reused KVM_EXIT_IRQ_WINDOW_OPEN as exit reason, for it would doing nothing at all in userspace handler. This can be done from userspace, by scheduling a SIGALRM in the desired frequency. This way, userspace has control over the update frequency (for example, if the SDL window is minimized or VNC is disconnected, we don't need to poll). I think we can even do this from the I/O thread, without stopping a vcpu, since the colaesced mmio page is not tied to a vcpu but is a vm property. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
On Wednesday 20 January 2010 17:11:51 Avi Kivity wrote:
On 01/20/2010 10:35 AM, Sheng Yang wrote:
The default action of calesced MMIO is, cache the writing in buffer,
until: 1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No need for input or accessing other devices frequently.
This issue was observed in a experimental embbed system. The test image
simply print test every 1 seconds. The output in QEmu meets
expectation, but the output in KVM is delayed for seconds.
To solve this issue, a timeout is added, to ensure userspace exit
freqency is high enough(mostly target for video now) to write the
buffered MMIO data. Current the maximum exit interval is 1/25s(so 25
times exit to userspace per second at least, pretty low compared to
normal environment), and reused KVM_EXIT_IRQ_WINDOW_OPEN as exit reason,
for it would doing nothing at all in userspace handler.
This can be done from userspace, by scheduling a SIGALRM in the desired
frequency. This way, userspace has control over the update frequency
(for example, if the SDL window is minimized or VNC is disconnected, we
don't need to poll).
I also thought of using alarm from userspace. But the issue I thought is a
SIGALRM should shoot
down a vcpu unconditionally. I think in the real world, this situation is not
that common, but
the SIGALRM would definitely bring overhead in every situation. So I choose the
current method -
though still not that elegant.
I think we can even do this from the I/O thread, without stopping a
vcpu, since the colaesced mmio page is not tied to a vcpu but is a vm
property.
This one sounds better. But I've taken a look at the current userspace code:
#if defined(KVM_CAP_COALESCED_MMIO)
if (kvm_state-coalesced_mmio) {
struct kvm_coalesced_mmio_ring *ring =
(void *) run + kvm_state-coalesced_mmio * PAGE_SIZE;
while (ring-first != ring-last) {
cpu_physical_memory_rw(ring-coalesced_mmio[ring-first].phys_addr,
ring-coalesced_mmio[ring-first].data[0],
ring-coalesced_mmio[ring-first].len, 1);
smp_wmb();
ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX;
}
}
#endif
No protection for ring-first and ring-last? Seems it can writing the same
element pointed by
ring-first twice, then skip one element at (ring-first + 1)...
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
On 01/20/2010 11:34 AM, Sheng Yang wrote:
I think we can even do this from the I/O thread, without stopping a
vcpu, since the colaesced mmio page is not tied to a vcpu but is a vm
property.
This one sounds better. But I've taken a look at the current userspace code:
#if defined(KVM_CAP_COALESCED_MMIO)
if (kvm_state-coalesced_mmio) {
struct kvm_coalesced_mmio_ring *ring =
(void *) run + kvm_state-coalesced_mmio * PAGE_SIZE;
while (ring-first != ring-last) {
cpu_physical_memory_rw(ring-coalesced_mmio[ring-first].phys_addr,
ring-coalesced_mmio[ring-first].data[0],
ring-coalesced_mmio[ring-first].len, 1);
smp_wmb();
ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX;
}
}
#endif
No protection for ring-first and ring-last? Seems it can writing the same
element pointed by
ring-first twice, then skip one element at (ring-first + 1)...
ring-first is owned by userspace, while ring-last is owned by the
kernel, so no protection is necessary except for the memory barrier.
Can you elaborate on how it would fail?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
On Wednesday 20 January 2010 17:47:48 Avi Kivity wrote:
On 01/20/2010 11:34 AM, Sheng Yang wrote:
I think we can even do this from the I/O thread, without stopping a
vcpu, since the colaesced mmio page is not tied to a vcpu but is a vm
property.
This one sounds better. But I've taken a look at the current userspace
code:
#if defined(KVM_CAP_COALESCED_MMIO)
if (kvm_state-coalesced_mmio) {
struct kvm_coalesced_mmio_ring *ring =
(void *) run + kvm_state-coalesced_mmio * PAGE_SIZE;
while (ring-first != ring-last) {
cpu_physical_memory_rw(ring-coalesced_mmio[ring-first].phys_addr,
ring-coalesced_mmio[ring-first].data[0],
ring-coalesced_mmio[ring-first].len, 1); smp_wmb();
ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX;
}
}
#endif
No protection for ring-first and ring-last? Seems it can writing the
same element pointed by ring-first twice, then skip one element at
(ring-first + 1)...
ring-first is owned by userspace, while ring-last is owned by the
kernel, so no protection is necessary except for the memory barrier.
Can you elaborate on how it would fail?
This piece of code can only be executed on one thread/vcpu at same time? I
think different vcpus accessing/modifying ring-first at the same time would
cause problem.
But for a separate iothread which handle all userspace accessing, it should be
fine.
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/12] Add handle page fault PV helper.
On Tue, Jan 19, 2010 at 12:10:17PM -0800, H. Peter Anvin wrote: On 01/19/2010 09:44 AM, Gleb Natapov wrote: Yes it can be done this way and I'll look into it once more. Using exception vector is more convenient for three reasons: it allows to pass additional data in error code, it doesn't require guest to issue EOI, exception can be injected when interrupts are disabled by a guest. The last one is not important for now since host doesn't inject notifications when interrupts are disabled currently. Having Intel allocate one exception vector for hypervisor use would be really nice though. That's probably not going to happen, for the rather obvious reason: *you already have 224 of them*. You seem to be thinking here that vectors 0-31 have to be exceptions and 32-255 have to be interrupts. *There is no such distinction*; the only thing special about 0-31 is that we (Intel) reserve the right to control the assignments; for 32-255 the platform and OS control the assignment. I would be glad to interpret the spec like you do, but table 6-1 SDM 3A mark vectors 2,32-255 as interrupts while others are traps, fault and aborts. Unfortunately VMX designers seems to be interpreting the spec like I do. See below. You can have the guest OS take an exception on a vector above 31 just fine; you just need it to tell the hypervisor which vector it, the OS, assigned for this purpose. VMX doesn't allow to inject hardware exception with vector greater then 31. SDM 3B section 23.2.1.3. I can inject the event as HW interrupt on vector greater then 32 but not go through APIC so EOI will not be required. This sounds non-architectural and I am not sure kernel has entry point code for this kind of event, it has one for exception and one for interrupts that goes through __do_IRQ() which assumes that interrupts should be ACKed. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to single-step in kvm, always results in a resume
Hi Nicholas, please don't drop CCs on reply. Nicholas Amon wrote: Hi Jan, Thanks for responding. Yes, I am able to step instruction when I disable kvm w/ the no-kvm option. My host kernel is 64bit 2.6.27 and the program that I am debugging is 32 bit but starts in real mode. But the KVM module I am running is from kvm-88. Is there anyway I can check the version definitively? kvm modules issue a message when being loaded, check your kernel log. qemu-kvm gives you the version via -version. OK, the problems you see is likely related to the very old versions you use. Update to recent kvm-kmod (2.6.32 series) and qemu-kvm (0.12 series) and retry. Jan Thanks, Nicholas Jan Kiszka wrote: Jan Kiszka wrote: Nicholas Amon wrote: Hi All, I am trying to single-step through my kernel using qemu and kvm. I have run qemu via: qemu-system-x86_64 -s -S -hda /home/nickamon/lab1/obj/kernel.img and also connected to the process using gdb. Problem is that whenever I try and step instruction, it seems to resume my kernel rather than allowing me to progress instruction by instruction. I have built the kvm snapshot from git and still no luck. Tried following the code for a few hours and have no luck. Any suggestions? What's you host kernel or kvm-kmod version? ...and does -no-kvm make any difference (except that it's much slower)? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Segfault
When I start qemu-img with strace I get the output below. Does
this help to to identify the problem?
scotty images # strace qemu-img convert -f qcow2 nweb.img -O raw test.img
execve(/usr/bin/qemu-img, [qemu-img, convert, -f, qcow2,
nweb.img, -O, raw, test.img], [/* 44 vars */]) = 0
brk(0) = 0x635000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fc6ec61a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fc6ec619000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/usr/lib64/tls/x86_64/librt.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/tls/x86_64, 0x7f9a4cd0) = -1 ENOENT (No such file
or directory)
open(/usr/lib64/tls/librt.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat(/usr/lib64/tls, {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
open(/usr/lib64/x86_64/librt.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat(/usr/lib64/x86_64, 0x7f9a4cd0) = -1 ENOENT (No such file or
directory)
open(/usr/lib64/librt.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat(/usr/lib64, {st_mode=S_IFDIR|0755, st_size=147456, ...}) = 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=207105, ...}) = 0
mmap(NULL, 207105, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc6ec5e6000
close(3)= 0
open(/lib/librt.so.1, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\340\\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=35656, ...}) = 0
mmap(NULL, 2132976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fc6ec1f6000
mprotect(0x7fc6ec1fe000, 2093056, PROT_NONE) = 0
mmap(0x7fc6ec3fd000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fc6ec3fd000
close(3)= 0
open(/usr/lib64/tls/libpthread.so.0, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/lib64/libpthread.so.0, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/lib/libpthread.so.0, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\340W\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=132454, ...}) = 0
mmap(NULL, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fc6ebfdb000
mprotect(0x7fc6ebff1000, 2093056, PROT_NONE) = 0
mmap(0x7fc6ec1f, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7fc6ec1f
mmap(0x7fc6ec1f2000, 13168, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec1f2000
close(3)= 0
open(/usr/lib64/tls/libaio.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/usr/lib64/libaio.so.1, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0`\6\0\0\0\0\0\0..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=5280, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fc6ec5e5000
mmap(NULL, 2101296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fc6ebdd9000
mprotect(0x7fc6ebdda000, 2093056, PROT_NONE) = 0
mmap(0x7fc6ebfd9000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fc6ebfd9000
close(3)= 0
open(/usr/lib64/tls/libz.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/lib64/libz.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/lib/libz.so.1, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0
\0\0\0\0\0\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=84272, ...}) = 0
mmap(NULL, 2179568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fc6ebbc4000
mprotect(0x7fc6ebbd8000, 2093056, PROT_NONE) = 0
mmap(0x7fc6ebdd7000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x7fc6ebdd7000
close(3)= 0
open(/usr/lib64/tls/libcurl.so.4, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/usr/lib64/libcurl.so.4, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0\310\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=279672, ...}) = 0
mmap(NULL, 2375624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fc6eb98
mprotect(0x7fc6eb9c2000, 2097152, PROT_NONE) = 0
mmap(0x7fc6ebbc2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x42000) = 0x7fc6ebbc2000
close(3)= 0
open(/usr/lib64/tls/libgssapi_krb5.so.2, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/lib64/libgssapi_krb5.so.2, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0j\0\0\0\0\0\0..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=173272, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fc6ec5e4000
mmap(NULL, 2268688, PROT_READ|PROT_EXEC,
[KVM PATCH] pci passthrough: zap option rom scanning.
Nowdays (qemu 0.12) seabios loads option roms from pci rom bars. So
there is no need any more to scan for option roms and have qemu load
them. Zap the code.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/device-assignment.c | 75
1 files changed, 0 insertions(+), 75 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index f4a1e32..e347d15 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1498,77 +1498,6 @@ void add_assigned_devices(PCIBus *bus, const char
**devices, int n_devices)
}
}
-/* Option ROM header */
-struct option_rom_header {
-uint8_t signature[2];
-uint8_t rom_size;
-uint32_t entry_point;
-uint8_t reserved[17];
-uint16_t pci_header_offset;
-uint16_t expansion_header_offset;
-} __attribute__ ((packed));
-
-/* Option ROM PCI data structure */
-struct option_rom_pci_header {
-uint8_t signature[4];
-uint16_t vendor_id;
-uint16_t device_id;
-uint16_t vital_product_data_offset;
-uint16_t structure_length;
-uint8_t structure_revision;
-uint8_t class_code[3];
-uint16_t image_length;
-uint16_t image_revision;
-uint8_t code_type;
-uint8_t indicator;
-uint16_t reserved;
-} __attribute__ ((packed));
-
-/*
- * Scan the list of Option ROMs at roms. If a suitable Option ROM is found,
- * allocate a ram space and copy it there. Then return its size aligned to
- * both 2KB and target page size.
- */
-#define OPTION_ROM_ALIGN(x) (((x) + 2047) ~2047)
-static void scan_option_rom(const char *name, uint8_t devfn, void *roms)
-{
-int i, size;
-uint8_t csum;
-struct option_rom_header *rom;
-struct option_rom_pci_header *pcih;
-
-rom = roms;
-
-for ( ; ; ) {
-/* Invalid signature means we're out of option ROMs. */
-if (strncmp((char *)rom-signature, \x55\xaa, 2) ||
- (rom-rom_size == 0))
-break;
-
-size = rom-rom_size * 512;
-/* Invalid checksum means we're out of option ROMs. */
-csum = 0;
-for (i = 0; i size; i++)
-csum += ((uint8_t *)rom)[i];
-if (csum != 0)
-break;
-
-/* Check the PCI header (if any) for a match. */
-pcih = (struct option_rom_pci_header *)
-((char *)rom + rom-pci_header_offset);
-if ((rom-pci_header_offset != 0)
- !strncmp((char *)pcih-signature, PCIR, 4))
-goto found;
-
-rom = (struct option_rom_header *)((char *)rom + size);
-}
-return;
-
- found:
-rom_add_blob(name ? name : assigned device, rom, size, 0);
-return;
-}
-
/*
* Scan the assigned devices for the devices that have an option ROM, and then
* load the corresponding ROM data to RAM. If an error occurs while loading an
@@ -1632,9 +1561,5 @@ static void assigned_dev_load_option_rom(AssignedDevice
*dev)
size, PROT_READ);
}
-if (!dev-dev.qdev.hotplugged) {
-/* Scan the buffer for suitable ROMs and increase the offset */
-scan_option_rom(dev-dev.qdev.id, dev-dev.devfn, buf);
-}
free(buf);
}
--
1.6.5.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO
On 01/20/2010 11:57 AM, Sheng Yang wrote: No protection for ring-first and ring-last? Seems it can writing the same element pointed by ring-first twice, then skip one element at (ring-first + 1)... ring-first is owned by userspace, while ring-last is owned by the kernel, so no protection is necessary except for the memory barrier. Can you elaborate on how it would fail? This piece of code can only be executed on one thread/vcpu at same time? I think different vcpus accessing/modifying ring-first at the same time would cause problem. Yes, it's protected by qemu_lock. But for a separate iothread which handle all userspace accessing, it should be fine. coalesced mmio processing can happen as part of vcpu processing (due to an mmio exit) or by the iothread (forced by the display refresh timer for example), but still serialized by qemu_lock. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: only allow one gsi per fd
On Sun, Jan 17, 2010 at 02:40:13PM +0200, Avi Kivity wrote: On 01/13/2010 06:58 PM, Michael S. Tsirkin wrote: Looks like repeatedly binding same fd to multiple gsi's with irqfd can use up a ton of kernel memory for irqfd structures. A simple fix is to allow each fd to only trigger one gsi: triggering a srorm of interrupts in guest is likely useless anyway, and we can do it by binding a single gsi to many interrupts if we really want to. Applied and queued, thanks. I'm guessing we need this for 2.6.32 stable and 2.6.33 as well? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Use compile_prog as rest of configure
This substitution got missed somehow
Signed-off-by: Juan Quintela quint...@redhat.com
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 20c374a..be739e1 100755
--- a/configure
+++ b/configure
@@ -1747,7 +1747,7 @@ cat $TMPC EOF
int main(void) { return syscall(SYS_signalfd, -1, NULL, _NSIG / 8); }
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null ; then
+if compile_prog ; then
signalfd=yes
fi
--
1.6.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] KVM test: Make sure setup does not execute on unattended install
- Lucas Meneghel Rodrigues l...@redhat.com wrote: If we are going unattended install, make sure the step based setup doesn't run, as the unattended install procedure already takes care of guest setup. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests.cfg.sample |2 +- client/tests/kvm/tests_base.cfg.sample | 16 +--- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/client/tests/kvm/tests.cfg.sample b/client/tests/kvm/tests.cfg.sample index c6a66a4..72a5d76 100644 --- a/client/tests/kvm/tests.cfg.sample +++ b/client/tests/kvm/tests.cfg.sample @@ -60,7 +60,7 @@ variants: only WinXP.32 no install setup no hugepages -only unattended_install setup boot shutdown +only unattended_install boot shutdown only rtl8139 - @fc11_kickstart: only qemu-kvm diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 0ab7823..15d137f 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -53,8 +53,17 @@ variants: kill_vm_timeout = 60 kill_vm_timeout_on_error = 0 +- setup:install +type = steps +fail_if_stuck_for = 300 +stuck_detection_history = 2does +kill_vm_on_error = yes +keep_screendump_history = yes + - unattended_install: type = unattended_install +# Unattended install also perform guest setup, so setup is not needed +no setup This line isn't going to have any effect, because there's no 'setup' in unattended_install anyway, because unattended_install inherits everything defined _before_ the current variants block, which I think is just some global defaults. In other words, unattended_install is separate from 'setup', it doesn't contain it. In order to prevent 'setup' from running before/after unattended_install we should modify the relevant test sets in tests.cfg (which is what the first part of this patch does). kill_vm_on_error = yes force_create_image = yes pre_command = scripts/unattended.py @@ -62,13 +71,6 @@ variants: extra_params += -boot d nic_mode = user -- setup:install unattended_install -type = steps -fail_if_stuck_for = 300 -stuck_detection_history = 2 -kill_vm_on_error = yes -keep_screendump_history = yes - - boot: install setup unattended_install type = boot kill_vm_on_error = yes -- 1.6.5.2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: only allow one gsi per fd
On 01/20/2010 01:36 PM, Michael S. Tsirkin wrote: On Sun, Jan 17, 2010 at 02:40:13PM +0200, Avi Kivity wrote: On 01/13/2010 06:58 PM, Michael S. Tsirkin wrote: Looks like repeatedly binding same fd to multiple gsi's with irqfd can use up a ton of kernel memory for irqfd structures. A simple fix is to allow each fd to only trigger one gsi: triggering a srorm of interrupts in guest is likely useless anyway, and we can do it by binding a single gsi to many interrupts if we really want to. Applied and queued, thanks. I'm guessing we need this for 2.6.32 stable and 2.6.33 as well? That's what 'queued' means. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/12] Add handle page fault PV helper.
On 01/20/2010 12:02 PM, Gleb Natapov wrote: I can inject the event as HW interrupt on vector greater then 32 but not go through APIC so EOI will not be required. This sounds non-architectural and I am not sure kernel has entry point code for this kind of event, it has one for exception and one for interrupts that goes through __do_IRQ() which assumes that interrupts should be ACKed. Further, we start to interact with the TPR; Linux doesn't use the TPR or cr8 but if it does one day we don't want it interfering with apf. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: only allow one gsi per fd
On Wed, Jan 20, 2010 at 01:52:00PM +0200, Avi Kivity wrote: On 01/20/2010 01:36 PM, Michael S. Tsirkin wrote: On Sun, Jan 17, 2010 at 02:40:13PM +0200, Avi Kivity wrote: On 01/13/2010 06:58 PM, Michael S. Tsirkin wrote: Looks like repeatedly binding same fd to multiple gsi's with irqfd can use up a ton of kernel memory for irqfd structures. A simple fix is to allow each fd to only trigger one gsi: triggering a srorm of interrupts in guest is likely useless anyway, and we can do it by binding a single gsi to many interrupts if we really want to. Applied and queued, thanks. I'm guessing we need this for 2.6.32 stable and 2.6.33 as well? That's what 'queued' means. Aha. Which git branch is used for these? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: only allow one gsi per fd
On 01/20/2010 01:59 PM, Michael S. Tsirkin wrote: I'm guessing we need this for 2.6.32 stable and 2.6.33 as well? That's what 'queued' means. Aha. Which git branch is used for these? kvm-updates/2.6.33. Cc: sta...@kernel.org means it will get auto-submitted to 2.6.32. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM test: Enable qemu upstream testing
- Lucas Meneghel Rodrigues l...@redhat.com wrote: qemu upstream has slight differences regarding qemu-kvm on the set of flags it supports. One of the most important differences is that on qemu we have to set -enable-kvm explicitely. Take this into consideration on the base configuration files and enable people to test qemu upstream more easily. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests.cfg.sample | 10 ++ client/tests/kvm/tests_base.cfg.sample |6 ++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/tests.cfg.sample b/client/tests/kvm/tests.cfg.sample index 74c94b4..c6a66a4 100644 --- a/client/tests/kvm/tests.cfg.sample +++ b/client/tests/kvm/tests.cfg.sample @@ -20,11 +20,17 @@ include cdkeys.cfg #cdrom.* ?= /tmp/kvm_autotest_root/ #steps ?= /tmp/kvm_autotest_root/ +# You will notice that in all test definition blocks we have 'only qemu-kvm' +# set. This means that qemu-kvm command line syntax will be used. If you +# intend to test qemu upstream, you'll have to change that to 'only qemu'. variants: - @full: +only qemu-kvm - @sample1: +only qemu-kvm only Fedora Windows - @sample2: +only qemu-kvm only qcow2 only ide only default @@ -32,9 +38,11 @@ variants: only Fedora.9.* RHEL.5.* Windows only rtl8139 - @sample3: +only qemu-kvm only qcow2.*ide.*default.*up.*Ubuntu-8.10-server.*(autotest.sleeptest) only rtl8139 - @fc8_step: +only qemu-kvm only qcow2 only ide only default @@ -44,6 +52,7 @@ variants: only rtl8139 only hugepages - @winXP_32_unattended: +only qemu-kvm only qcow2 only ide only default @@ -54,6 +63,7 @@ variants: only unattended_install setup boot shutdown only rtl8139 - @fc11_kickstart: +only qemu-kvm only qcow2 only ide only default diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index a63cc52..b1b1539 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -891,6 +891,12 @@ linux_s3: variants: +- @qemu-kvm: +- qemu: +extra_params += -enable-kvm + + +variants: - @up: no autotest.npb - smp2: Alternatively we can provide an example qemu test set in tests.cfg.sample -- something like this: - @fc11_kickstart: only qcow2 only ide only default ... - @qemu_fc11_kickstart: only qcow2 only ide only default ... extra_params += -enable-kvm Or we can allow the user to change extra_params like this (in tests.cfg.sample, before or after the test sets): # Uncomment this line if you would like to test upstream qemu #extra_params += -enable-kvm The problem with doing it the way you did is that there will never be a test set that runs both qemu and qemu-kvm (sequentially). A user will always run either qemu-kvm or qemu, not both. Is this correct? In that case 'qemu' is more like a flag than a variant, because it's global and applies to the entire job. On the other hand, there could be advantages to doing it your way, so I'm not quite sure what's better. What motivates me to comment on this is that we shouldn't have a variant for every little thing because each variants block doubles the number of dicts, slows down parsing and lengthens the full name of all tests. This is no big deal, but we should be just a little picky about the variants we define. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM test: tests_base.cfg updated with windows unattended install
- Lucas Meneghel Rodrigues l...@redhat.com wrote: Update the config file tests_base.cfg with the recently added windows unattended install files (r4109), so one is actually able to use them on tests. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests_base.cfg.sample | 40 +++- 1 files changed, 39 insertions(+), 1 deletions(-) diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index b8f25f4..a41a848 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -577,6 +577,9 @@ variants: cpu_chk_cmd = echo %NUMBER_OF_PROCESSORS% mem_chk_cmd = wmic memphysical +unattended_install: +timeout = 7200 +finish_program = deps/finish.exe migrate: migration_test_command = ver vol migration_bg_command = start ping -t localhost @@ -648,7 +651,6 @@ variants: md5sum = 743450644b1d9fe97b3cf379e22dceb0 md5sum_1m = b473bf75af2d1269fec8958cf0202bfd unattended_file = unattended/winxp32.sif -finish_program = deps/finish.exe setup: steps = WinXP-32-rss.steps @@ -678,6 +680,11 @@ variants: md5sum = 03e921e9b4214773c21a39f5c3f42ef7 md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 user = user +unattended_install: +cdrom = windows/Windows2003_r2_VLK.iso +md5sum = 03e921e9b4214773c21a39f5c3f42ef7 +md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 +unattended_file = unattended/win2003-32.sif setup: steps = Win2003-32-rss.steps Some code can be saved by using the fact that install and unattended_install use the same ISOs: install|unattended_install: cdrom = windows/Windows2003_r2_VLK.iso md5sum = 03e921e9b4214773c21a39f5c3f42ef7 md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 install: user = user unattended_install: unattended_file = unattended/win2003-32.sif It's not important, just an alternative to consider. @@ -689,9 +696,15 @@ variants: md5sum = 5703f87c9fd77d28c05ffadd3354dbbd md5sum_1m = 439393c384116aa09e08a0ad047dcea8 user = user +unattended_install: +cdrom = windows/Windows2003-x64.iso +md5sum = 5703f87c9fd77d28c05ffadd3354dbbd +md5sum_1m = 439393c384116aa09e08a0ad047dcea8 +unattended_file = unattended/win2003-64.sif setup: steps = Win2003-64-rss.steps + - WinVista: image_name = winvista image_size = 20G @@ -704,6 +717,11 @@ variants: cdrom = windows/WindowsVista-32.iso md5sum = 1008f323d5170c8e614e52ccb85c0491 md5sum_1m = c724e9695da483bc0fd59e426eaefc72 +unattended_install: +cdrom = windows/WindowsVista-32.iso +md5sum = 1008f323d5170c8e614e52ccb85c0491 +md5sum_1m = c724e9695da483bc0fd59e426eaefc72 +unattended_file = unattended/winvista-32-autounattend.xml setup: steps = WinVista-32-rss.steps @@ -714,6 +732,11 @@ variants: cdrom = windows/WindowsVista-64.iso md5sum = 11e2010d857fffc47813295e6be6d58d md5sum_1m = 0947bcd5390546139e25f25217d6f165 +unattended_install: +cdrom = windows/WindowsVista-64.iso +md5sum = 11e2010d857fffc47813295e6be6d58d +md5sum_1m = 0947bcd5390546139e25f25217d6f165 +unattended_file = unattended/winvista-64-autounattend.xml setup: steps = WinVista-64-rss.steps @@ -733,6 +756,11 @@ variants: #sha1sum = 6CA018FF96F1E9B2B310A36546B6FDED99A421E6 md5sum=0bfca49f0164de0a8eba236ced47007d md5sum_1m=07d7f5006393f74dc76e6e2e943e2440 +unattended_install: +cdrom = windows/Windows2008-x86.iso +
Re: [PATCH] KVM test: Enable qemu upstream testing
On Wed, 2010-01-20 at 08:24 -0500, Michael Goldish wrote: - Lucas Meneghel Rodrigues l...@redhat.com wrote: qemu upstream has slight differences regarding qemu-kvm on the set of flags it supports. One of the most important differences is that on qemu we have to set -enable-kvm explicitely. Take this into consideration on the base configuration files and enable people to test qemu upstream more easily. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests.cfg.sample | 10 ++ client/tests/kvm/tests_base.cfg.sample |6 ++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/tests.cfg.sample b/client/tests/kvm/tests.cfg.sample index 74c94b4..c6a66a4 100644 --- a/client/tests/kvm/tests.cfg.sample +++ b/client/tests/kvm/tests.cfg.sample @@ -20,11 +20,17 @@ include cdkeys.cfg #cdrom.* ?= /tmp/kvm_autotest_root/ #steps ?= /tmp/kvm_autotest_root/ +# You will notice that in all test definition blocks we have 'only qemu-kvm' +# set. This means that qemu-kvm command line syntax will be used. If you +# intend to test qemu upstream, you'll have to change that to 'only qemu'. variants: - @full: +only qemu-kvm - @sample1: +only qemu-kvm only Fedora Windows - @sample2: +only qemu-kvm only qcow2 only ide only default @@ -32,9 +38,11 @@ variants: only Fedora.9.* RHEL.5.* Windows only rtl8139 - @sample3: +only qemu-kvm only qcow2.*ide.*default.*up.*Ubuntu-8.10-server.*(autotest.sleeptest) only rtl8139 - @fc8_step: +only qemu-kvm only qcow2 only ide only default @@ -44,6 +52,7 @@ variants: only rtl8139 only hugepages - @winXP_32_unattended: +only qemu-kvm only qcow2 only ide only default @@ -54,6 +63,7 @@ variants: only unattended_install setup boot shutdown only rtl8139 - @fc11_kickstart: +only qemu-kvm only qcow2 only ide only default diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index a63cc52..b1b1539 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -891,6 +891,12 @@ linux_s3: variants: +- @qemu-kvm: +- qemu: +extra_params += -enable-kvm + + +variants: - @up: no autotest.npb - smp2: Alternatively we can provide an example qemu test set in tests.cfg.sample -- something like this: - @fc11_kickstart: only qcow2 only ide only default ... - @qemu_fc11_kickstart: only qcow2 only ide only default ... extra_params += -enable-kvm Indeed, I agree. I chose to make another block because some times it's desirable to test both qemu-kvm and qemu (see below): Or we can allow the user to change extra_params like this (in tests.cfg.sample, before or after the test sets): # Uncomment this line if you would like to test upstream qemu #extra_params += -enable-kvm The problem with doing it the way you did is that there will never be a test set that runs both qemu and qemu-kvm (sequentially). A user will always run either qemu-kvm or qemu, not both. Is this correct? In that case 'qemu' is more like a flag than a variant, because it's global and applies to the entire job. Not quite, on our upstream job I've enabled qemu-kvm and qemu test on the same job, that's why I think it's a good idea. On the other hand, there could be advantages to doing it your way, so I'm not quite sure what's better. What motivates me to comment on this is that we shouldn't have a variant for every little thing because each variants block doubles the number of dicts, slows down parsing and lengthens the full name of all tests. This is no big deal, but we should be just a little picky about the variants we define. I agree, in this case it's worth to keep it as a variants block. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM test: tests_base.cfg updated with windows unattended install
On Wed, 2010-01-20 at 08:33 -0500, Michael Goldish wrote: - Lucas Meneghel Rodrigues l...@redhat.com wrote: Update the config file tests_base.cfg with the recently added windows unattended install files (r4109), so one is actually able to use them on tests. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests_base.cfg.sample | 40 +++- 1 files changed, 39 insertions(+), 1 deletions(-) diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index b8f25f4..a41a848 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -577,6 +577,9 @@ variants: cpu_chk_cmd = echo %NUMBER_OF_PROCESSORS% mem_chk_cmd = wmic memphysical +unattended_install: +timeout = 7200 +finish_program = deps/finish.exe migrate: migration_test_command = ver vol migration_bg_command = start ping -t localhost @@ -648,7 +651,6 @@ variants: md5sum = 743450644b1d9fe97b3cf379e22dceb0 md5sum_1m = b473bf75af2d1269fec8958cf0202bfd unattended_file = unattended/winxp32.sif -finish_program = deps/finish.exe setup: steps = WinXP-32-rss.steps @@ -678,6 +680,11 @@ variants: md5sum = 03e921e9b4214773c21a39f5c3f42ef7 md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 user = user +unattended_install: +cdrom = windows/Windows2003_r2_VLK.iso +md5sum = 03e921e9b4214773c21a39f5c3f42ef7 +md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 +unattended_file = unattended/win2003-32.sif setup: steps = Win2003-32-rss.steps Some code can be saved by using the fact that install and unattended_install use the same ISOs: install|unattended_install: cdrom = windows/Windows2003_r2_VLK.iso md5sum = 03e921e9b4214773c21a39f5c3f42ef7 md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 install: user = user unattended_install: unattended_file = unattended/win2003-32.sif It's not important, just an alternative to consider. Good point, we should probably go over the config files upstream and do all these small adjustments. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: fix spurious interrupt with irqfd
On 01/19/2010 04:52 PM, Michael S. Tsirkin wrote: On Sun, Jan 17, 2010 at 02:42:50PM +0200, Avi Kivity wrote: On 01/13/2010 07:12 PM, Michael S. Tsirkin wrote: Deassigning irqfd and assigning back caused spurious interrupt. fix this by clearing the counter on deassign. This is on top of davidel's patch which makes clearing eventfd counter from modules possible. Applied both, thanks. Hmm, I see this in kvm master. Avi/Marcelo, since this is a bugfix, can you queue this patchset for 2.6.33 and 2.6.32 stable as well please? I'm uncomfortable with pushing Davide's patch into stable and possibly causing regressions with unrelated applications. Can't a guest live with a spurious interrupt? It's not like they're unknown. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
On 01/19/2010 06:15 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as obscure as -cpu
qemu64,-sse3,+vmx,...
What name will these users know? FWIW, it makes sense to me as it is.
Whatever is in /proc/cpuinfo.
That doesn't exactly generalize to families w/ similar cpuid features.
Intel(R) Xeon(R) {E,L,X}{74,55}**
Intel(R) Core(TM)2 {Duo,Quad,Extreme} ...
Then we should key off of family and model.
So -cpu AMD_Family_10h
or something like that. At least that is discoverable by a user.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Qemu 0.10.5 does not delete pidfile after machine shutdown
Hi there, i have a problem with the -pidfile ... option in qemu 0.10.50. If I start the machine, the pidfile with the correct PID will be created. After shutdown the pidfile still exists. How can I instruct qemu to delete the pidfile after machine shutdown? Regards, Tobias Es wird ein guter Tag. Mit Sirona. Enjoy every day. With Sirona. Sirona Dental Systems GmbH . HRB 24948 . Vorsitzender des Aufsichtsrats: Dr. Erich Blum . Sirona Dental Services GmbH . HRB 25819 . Sirona Holding GmbH . HRB 25817 . Sirona Immobilien GmbH . HRB 24987 . Sirona International Holding GmbH . HRB 25741 . Sirona Technologie GmbH Co. KG . HRA 83590 . Geschaftsfuhrung: Theo Haar . Sitz der Gesellschaften: Bensheim . Registergericht: AG Darmstadt . Diese E-Mail ist ausschliesslich fuer den angesprochenen Adressaten bestimmt und kann vertrauliche Informationen beinhalten. Wenn Sie diese E-Mail irrtuemlich erhalten haben, verstaendigen Sie uns bitte umgehend unter postmas...@sirona.com und loeschen die E-Mail. Sie duerfen die E-Mail nicht kopieren, verteilen, veroeffentlichen oder sonst in irgendeiner Weise verwenden. This e-mail is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to other confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. If you receive this in error, please notify us immediately at postmas...@sirona.com and delete this message -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
On Wed, Jan 20, 2010 at 08:21:44AM -0600, Anthony Liguori wrote:
On 01/19/2010 06:15 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as obscure as -cpu
qemu64,-sse3,+vmx,...
What name will these users know? FWIW, it makes sense to me as it is.
Whatever is in /proc/cpuinfo.
That doesn't exactly generalize to families w/ similar cpuid features.
Intel(R) Xeon(R) {E,L,X}{74,55}**
Intel(R) Core(TM)2 {Duo,Quad,Extreme} ...
Then we should key off of family and model.
So -cpu AMD_Family_10h
or something like that. At least that is discoverable by a user.
Or use CPU price/year as a distinguisher. -cpu Intel_300$_2005 will give
you Intel cpus that cost 300$ in 2005.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to single-step in kvm, always results in a resume
Thanks Jan. That fixed it. Nicholas Jan Kiszka wrote: Hi Nicholas, please don't drop CCs on reply. Nicholas Amon wrote: Hi Jan, Thanks for responding. Yes, I am able to step instruction when I disable kvm w/ the no-kvm option. My host kernel is 64bit 2.6.27 and the program that I am debugging is 32 bit but starts in real mode. But the KVM module I am running is from kvm-88. Is there anyway I can check the version definitively? kvm modules issue a message when being loaded, check your kernel log. qemu-kvm gives you the version via -version. OK, the problems you see is likely related to the very old versions you use. Update to recent kvm-kmod (2.6.32 series) and qemu-kvm (0.12 series) and retry. Jan Thanks, Nicholas Jan Kiszka wrote: Jan Kiszka wrote: Nicholas Amon wrote: Hi All, I am trying to single-step through my kernel using qemu and kvm. I have run qemu via: qemu-system-x86_64 -s -S -hda /home/nickamon/lab1/obj/kernel.img and also connected to the process using gdb. Problem is that whenever I try and step instruction, it seems to resume my kernel rather than allowing me to progress instruction by instruction. I have built the kvm snapshot from git and still no luck. Tried following the code for a few hours and have no luck. Any suggestions? What's you host kernel or kvm-kmod version? ...and does -no-kvm make any difference (except that it's much slower)? Jan -- Nicholas Amon Senior Software Engineer Xceedium Inc. Office: 201-536-1000 x127 Cell: 732-236-7698 na...@xceedium.com See How to Control Track High-Risk Users: Join our Webinar on Tuesday, June 2 Network World Names Xceedium GateKeeper RSA 2009 Best of Show -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: fix spurious interrupt with irqfd
On Wed, Jan 20, 2010 at 04:10:37PM +0200, Avi Kivity wrote: On 01/19/2010 04:52 PM, Michael S. Tsirkin wrote: On Sun, Jan 17, 2010 at 02:42:50PM +0200, Avi Kivity wrote: On 01/13/2010 07:12 PM, Michael S. Tsirkin wrote: Deassigning irqfd and assigning back caused spurious interrupt. fix this by clearing the counter on deassign. This is on top of davidel's patch which makes clearing eventfd counter from modules possible. Applied both, thanks. Hmm, I see this in kvm master. Avi/Marcelo, since this is a bugfix, can you queue this patchset for 2.6.33 and 2.6.32 stable as well please? I'm uncomfortable with pushing Davide's patch into stable and possibly causing regressions with unrelated applications. Can't a guest live with a spurious interrupt? Well guests mask/unmask vector on each interrupt, so this will trigger an irq storm I think. It's not like they're unknown. Depends on the device really. In theory, if they trigger at an unfortunate time this could cause crashes. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: fix spurious interrupt with irqfd
On 01/20/2010 04:58 PM, Michael S. Tsirkin wrote: I'm uncomfortable with pushing Davide's patch into stable and possibly causing regressions with unrelated applications. Can't a guest live with a spurious interrupt? Well guests mask/unmask vector on each interrupt, so this will trigger an irq storm I think. It's not like they're unknown. Depends on the device really. In theory, if they trigger at an unfortunate time this could cause crashes. I'd like confirmation on both of these before I push things to stable. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: fix spurious interrupt with irqfd
On Wed, Jan 20, 2010 at 05:09:32PM +0200, Avi Kivity wrote: On 01/20/2010 04:58 PM, Michael S. Tsirkin wrote: I'm uncomfortable with pushing Davide's patch into stable and possibly causing regressions with unrelated applications. Can't a guest live with a spurious interrupt? Well guests mask/unmask vector on each interrupt, so this will trigger an irq storm I think. It's not like they're unknown. Depends on the device really. In theory, if they trigger at an unfortunate time this could cause crashes. I'd like confirmation on both of these before I push things to stable. I have observed the interrupt storm. We end up with interrupt being disabled. Crash is a theoretical issue. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Compilation errors while compiling KVM 88
Hi all, I am having some errors when building KVM 88 module. I configured the package as follows: ./configure --prefix=/usr/local/kvm --kerneldir=/usr/src/kernels/linux-2.6.30.2 And then typed: make I am getting a lot of undefined reference errors. For example: xen_domainbuild.o: In function `xen_domain_poll': /root/kvm/kvm-88/hw/xen_domainbuild.c:139: undefined reference to `xc_domain_getinfo' xen_domainbuild.o: In function `xen_domain_cleanup': /root/kvm/kvm-88/hw/xen_domainbuild.c:215: undefined reference to `xs_get_domain_path' /root/kvm/kvm-88/hw/xen_domainbuild.c:217: undefined reference to `xs_rm' Option --disable-xendisable xen backend driver support did not solve the problem. How can I resolve this error ? Thanks, Lior Levy - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network shutdown under heavy load
On Tuesday 19 January 2010 05:57:53 pm Chris Wright wrote: * Tom Lendacky (t...@linux.vnet.ibm.com) wrote: On Wednesday 13 January 2010 03:52:28 pm Chris Wright wrote: (Mark cc'd, sound familiar?) * Tom Lendacky (t...@linux.vnet.ibm.com) wrote: On Sunday 10 January 2010 06:38:54 am Avi Kivity wrote: On 01/10/2010 02:35 PM, Herbert Xu wrote: On Sun, Jan 10, 2010 at 02:30:12PM +0200, Avi Kivity wrote: This isn't in 2.6.27.y. Herbert, can you send it there? It appears that now that TX is fixed we have a similar problem with RX. Once I figure that one out I'll send them together. I've been experiencing the network shutdown issue also. I've been running netperf tests across 10GbE adapters with Qemu 0.12.1.2, RHEL5.4 guests and 2.6.32 kernel (from kvm.git) guests. I instrumented Qemu to print out some network statistics. It appears that at some point in the netperf test the receiving guest ends up having the 10GbE device receive_disabled variable in its VLANClientState structure stuck at 1. From looking at the code it appears that the virtio-net driver in the guest should cause qemu_flush_queued_packets in net.c to eventually run and clear the receive_disabled variable but it's not happening. I don't seem to have these issues when I have a lot of debug settings active in the guest kernel which results in very low/poor network performance - maybe some kind of race condition? Ok, here's an update. After realizing that none of the ethtool offload options were enabled in my guest, I found that I needed to be using the -netdev option on the qemu command line. Once I did that, some ethtool offload options were enabled and the deadlock did not appear when I did networking between guests on different machines. However, the deadlock did appear when I did networking between guests on the same machine. What does your full command line look like? And when the networking stops does your same receive_disabled hack make things work? The command line when using the -net option for the tap device is: /usr/local/bin/qemu-system-x86_64 -name cape-vm001 -m 1024 -drive file=/autobench/var/tmp/cape-vm001- raw.img,if=virtio,index=0,media=disk,boot=on -net nic,model=virtio,vlan=0,macaddr=00:16:3E:00:62:51 -net tap,vlan=0,script=/autobench/var/tmp/ifup-kvm- br0,downscript=/autobench/var/tmp/ifdown-kvm-br0 -net nic,model=virtio,vlan=1,macaddr=00:16:3E:00:62:D1 -net tap,vlan=1,script=/autobench/var/tmp/ifup-kvm- br1,downscript=/autobench/var/tmp/ifdown-kvm-br1 -vnc :1 -monitor telnet::5701,server,nowait -snapshot -daemonize when using the -netdev option for the tap device: /usr/local/bin/qemu-system-x86_64 -name cape-vm001 -m 1024 -drive file=/autobench/var/tmp/cape-vm001- raw.img,if=virtio,index=0,media=disk,boot=on -net nic,model=virtio,vlan=0,macaddr=00:16:3E:00:62:51,netdev=cape-vm001-eth0 - netdev tap,id=cape-vm001-eth0,script=/autobench/var/tmp/ifup-kvm- br0,downscript=/autobench/var/tmp/ifdown-kvm-br0 -net nic,model=virtio,vlan=1,macaddr=00:16:3E:00:62:D1,netdev=cape-vm001-eth1 - netdev tap,id=cape-vm001-eth1,script=/autobench/var/tmp/ifup-kvm- br1,downscript=/autobench/var/tmp/ifdown-kvm-br1 -vnc :1 -monitor telnet::5701,server,nowait -snapshot -daemonize The first ethernet device is a 1GbE device for communicating with the automation infrastructure we have. The second ethernet device is the 10GbE device that the netperf tests run on. I can get the networking to work again by bringing down the interfaces and reloading the virtio_net module (modprobe -r virtio_net / modprobe virtio_net). I haven't had a chance yet to run the tests against a modified version of qemu that does not set the receive_disabled variable. Tom thanks, -chris -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compilation errors while compiling KVM 88
On 01/20/2010 05:13 PM, Levy, Lior wrote: Hi all, I am having some errors when building KVM 88 module. That's pretty old. Take a look at http://www.linux-kvm.org/page/Getting_the_kvm_kernel_modules. For userspace, use the qemu-kvm-0.12 series. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga stad / vga vmware leads to KVM internal error. Suberror: 1
On 01/14/2010 04:20 PM, Avi Kivity wrote: On 01/14/2010 04:06 PM, Dominik Brodowski wrote: x/5i $eip 0x7f317ab64a7b: movdqa %xmm0,(%rdi) 0x7f317ab64a7f: movdqa %xmm0,0x10(%rdi) 0x7f317ab64a84: movdqa %xmm0,0x20(%rdi) 0x7f317ab64a89: movdqa %xmm0,0x30(%rdi) 0x7f317ab64a8e: movdqa %xmm0,0x40(%rdi) Same values for vga vmware and vga std. Yes - this has been reported. We need to start emulating movdqa and a few of its friends. So I have a nice patchset emulating this instruction (quite a pain, since this is the first sse instruction we emulate), but it doesn't help. The guest keeps using it so the display is incredibly slow. Turns out the real problem is somewhere else - the guest is not detecting VBE properly so it is forced to use the old slow vga access. Not sure what the root cause is. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga stad / vga vmware leads to KVM internal error. Suberror: 1
On 01/20/2010 10:46 AM, Avi Kivity wrote: On 01/14/2010 04:20 PM, Avi Kivity wrote: On 01/14/2010 04:06 PM, Dominik Brodowski wrote: x/5i $eip 0x7f317ab64a7b: movdqa %xmm0,(%rdi) 0x7f317ab64a7f: movdqa %xmm0,0x10(%rdi) 0x7f317ab64a84: movdqa %xmm0,0x20(%rdi) 0x7f317ab64a89: movdqa %xmm0,0x30(%rdi) 0x7f317ab64a8e: movdqa %xmm0,0x40(%rdi) Same values for vga vmware and vga std. Yes - this has been reported. We need to start emulating movdqa and a few of its friends. So I have a nice patchset emulating this instruction (quite a pain, since this is the first sse instruction we emulate), but it doesn't help. The guest keeps using it so the display is incredibly slow. Turns out the real problem is somewhere else - the guest is not detecting VBE properly so it is forced to use the old slow vga access. Not sure what the root cause is. Is this with -vga std or -vga vmware? Is this a VESA driver in the guest? Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga stad / vga vmware leads to KVM internal error. Suberror: 1
On 01/20/2010 07:00 PM, Anthony Liguori wrote: So I have a nice patchset emulating this instruction (quite a pain, since this is the first sse instruction we emulate), but it doesn't help. The guest keeps using it so the display is incredibly slow. Turns out the real problem is somewhere else - the guest is not detecting VBE properly so it is forced to use the old slow vga access. Not sure what the root cause is. Is this with -vga std or -vga vmware? Yes (both reported, I confirmed with -vga std). Is this a VESA driver in the guest? So it seems from the Xorg log. Boot a Ubuntu 9.10 cdrom, on qemu-kvm-0.11 it boots fine and fast, on 0.12 it fails on emulation (unless you apply my patchset, in which case it works, but is incredibly slow). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for January 20 (kvm warnings)
On 01/20/2010 07:12 PM, Randy Dunlap wrote: On Wed, 20 Jan 2010 18:10:16 +1100 Stephen Rothwell wrote: Hi all, Changes since 20100119: The kvm tree lost its build failure. on i386/X86_32: arch/x86/kvm/x86.c:3810: warning: left shift count= width of type arch/x86/kvm/x86.c:3812: warning: left shift count= width of type arch/x86/kvm/x86.c:3814: warning: left shift count= width of type Gleb already posted a patch to fix this. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/12] Add handle page fault PV helper.
On 01/20/2010 07:00 AM, Avi Kivity wrote: On 01/20/2010 12:02 PM, Gleb Natapov wrote: I can inject the event as HW interrupt on vector greater then 32 but not go through APIC so EOI will not be required. This sounds non-architectural and I am not sure kernel has entry point code for this kind of event, it has one for exception and one for interrupts that goes through __do_IRQ() which assumes that interrupts should be ACKed. Further, we start to interact with the TPR; Linux doesn't use the TPR or cr8 but if it does one day we don't want it interfering with apf. That's not an issue is it? The guest will tell the host what vector to use for pseudo page faults. -- All rights reversed. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: fix spurious interrupt with irqfd
On Wed, 20 Jan 2010, Avi Kivity wrote: I'm uncomfortable with pushing Davide's patch into stable and possibly causing regressions with unrelated applications. Can't a guest live with a spurious interrupt? It's not like they're unknown. Better material for .33 instead of stable, I agree. - Davide -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Debug register emulation fixes and optimizations (reloaded)
Major parts of this series were already posted a while ago during the debug register switch optimizations. This version now comes with an additional fix for VMX (patch 1) and a rework of mov dr emulation for SVM. Find this series also at git://git.kiszka.org/linux-kvm.git queues/debugregs Jan Kiszka (5): KVM: VMX: Fix exceptions of mov to dr KVM: VMX: Fix emulation of DR4 and DR5 KVM: VMX: Clean up DR6 emulation KVM: SVM: Clean up and enhance mov dr emulation KVM: SVM: Trap all debug register accesses arch/x86/include/asm/kvm_host.h |5 +- arch/x86/kvm/svm.c | 78 +-- arch/x86/kvm/vmx.c | 67 +++-- arch/x86/kvm/x86.c | 19 + 4 files changed, 84 insertions(+), 85 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] KVM: VMX: Fix exceptions of mov to dr
Injecting GP without an error code is a bad idea (causes unhandled guest
exits). Moreover, we must not skip the instruction if we injected an
exception.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/vmx.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9f56110..4903b41 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3049,6 +3049,7 @@ static int handle_dr(struct kvm_vcpu *vcpu)
unsigned long val;
int dr, reg;
+ /* Do not handle if the CPL 0, will trigger GP on re-entry */
if (!kvm_require_cpl(vcpu, 0))
return 1;
dr = vmcs_readl(GUEST_DR7);
@@ -3103,20 +3104,22 @@ static int handle_dr(struct kvm_vcpu *vcpu)
vcpu-arch.eff_db[dr] = val;
break;
case 4 ... 5:
- if (kvm_read_cr4_bits(vcpu, X86_CR4_DE))
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE)) {
kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
break;
case 6:
if (val 0xULL) {
- kvm_queue_exception(vcpu, GP_VECTOR);
- break;
+ kvm_inject_gp(vcpu, 0);
+ return 1;
}
vcpu-arch.dr6 = (val DR6_VOLATILE) | DR6_FIXED_1;
break;
case 7:
if (val 0xULL) {
- kvm_queue_exception(vcpu, GP_VECTOR);
- break;
+ kvm_inject_gp(vcpu, 0);
+ return 1;
}
vcpu-arch.dr7 = (val DR7_VOLATILE) | DR7_FIXED_1;
if (!(vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP)) {
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] KVM: VMX: Fix emulation of DR4 and DR5
Make sure DR4 and DR5 are aliased to DR6 and DR7, respectively, if
CR4.DE is not set.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/vmx.c | 35 ++-
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4903b41..834a8eb 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3043,6 +3043,15 @@ static int handle_cr(struct kvm_vcpu *vcpu)
return 0;
}
+static int check_dr_alias(struct kvm_vcpu *vcpu)
+{
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE)) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return -1;
+ }
+ return 0;
+}
+
static int handle_dr(struct kvm_vcpu *vcpu)
{
unsigned long exit_qualification;
@@ -3085,14 +3094,20 @@ static int handle_dr(struct kvm_vcpu *vcpu)
case 0 ... 3:
val = vcpu-arch.db[dr];
break;
+ case 4:
+ if (check_dr_alias(vcpu) 0)
+ return 1;
+ /* fall through */
case 6:
val = vcpu-arch.dr6;
break;
- case 7:
+ case 5:
+ if (check_dr_alias(vcpu) 0)
+ return 1;
+ /* fall through */
+ default: /* 7 */
val = vcpu-arch.dr7;
break;
- default:
- val = 0;
}
kvm_register_write(vcpu, reg, val);
} else {
@@ -3103,12 +3118,10 @@ static int handle_dr(struct kvm_vcpu *vcpu)
if (!(vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP))
vcpu-arch.eff_db[dr] = val;
break;
- case 4 ... 5:
- if (kvm_read_cr4_bits(vcpu, X86_CR4_DE)) {
- kvm_queue_exception(vcpu, UD_VECTOR);
+ case 4:
+ if (check_dr_alias(vcpu) 0)
return 1;
- }
- break;
+ /* fall through */
case 6:
if (val 0xULL) {
kvm_inject_gp(vcpu, 0);
@@ -3116,7 +3129,11 @@ static int handle_dr(struct kvm_vcpu *vcpu)
}
vcpu-arch.dr6 = (val DR6_VOLATILE) | DR6_FIXED_1;
break;
- case 7:
+ case 5:
+ if (check_dr_alias(vcpu) 0)
+ return 1;
+ /* fall through */
+ default: /* 7 */
if (val 0xULL) {
kvm_inject_gp(vcpu, 0);
return 1;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] KVM: SVM: Clean up and enhance mov dr emulation
Enhance mov dr instruction emulation used by SVM so that it properly
handles dr4/5: alias to dr6/7 if cr4.de is cleared. Otherwise return
EMULATE_FAIL which will let our only possible caller in that scenario,
ud_interception, re-inject UD.
We do not need to inject faults, SVM does this for us (exceptions take
precedence over instruction interceptions). For the same reason, the
value overflow checks can be removed.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/include/asm/kvm_host.h |5 +--
arch/x86/kvm/svm.c | 64 ++-
arch/x86/kvm/x86.c | 19 +---
3 files changed, 33 insertions(+), 55 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a1f0b5d..d73ed48 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -506,9 +506,8 @@ struct kvm_x86_ops {
void (*set_idt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
void (*get_gdt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
void (*set_gdt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
- unsigned long (*get_dr)(struct kvm_vcpu *vcpu, int dr);
- void (*set_dr)(struct kvm_vcpu *vcpu, int dr, unsigned long value,
- int *exception);
+ int (*get_dr)(struct kvm_vcpu *vcpu, int dr, unsigned long *dest);
+ int (*set_dr)(struct kvm_vcpu *vcpu, int dr, unsigned long value);
void (*cache_reg)(struct kvm_vcpu *vcpu, enum kvm_reg reg);
unsigned long (*get_rflags)(struct kvm_vcpu *vcpu);
void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 8d7cb62..4295dfc 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1122,76 +1122,70 @@ static void new_asid(struct vcpu_svm *svm, struct
svm_cpu_data *sd)
svm-vmcb-control.asid = sd-next_asid++;
}
-static unsigned long svm_get_dr(struct kvm_vcpu *vcpu, int dr)
+static int svm_get_dr(struct kvm_vcpu *vcpu, int dr, unsigned long *dest)
{
struct vcpu_svm *svm = to_svm(vcpu);
- unsigned long val;
switch (dr) {
case 0 ... 3:
- val = vcpu-arch.db[dr];
+ *dest = vcpu-arch.db[dr];
break;
+ case 4:
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE))
+ return EMULATE_FAIL; /* will re-inject UD */
+ /* fall through */
case 6:
if (vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP)
- val = vcpu-arch.dr6;
+ *dest = vcpu-arch.dr6;
else
- val = svm-vmcb-save.dr6;
+ *dest = svm-vmcb-save.dr6;
break;
+ case 5:
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE))
+ return EMULATE_FAIL; /* will re-inject UD */
+ /* fall through */
case 7:
if (vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP)
- val = vcpu-arch.dr7;
+ *dest = vcpu-arch.dr7;
else
- val = svm-vmcb-save.dr7;
+ *dest = svm-vmcb-save.dr7;
break;
- default:
- val = 0;
}
- return val;
+ return EMULATE_DONE;
}
-static void svm_set_dr(struct kvm_vcpu *vcpu, int dr, unsigned long value,
- int *exception)
+static int svm_set_dr(struct kvm_vcpu *vcpu, int dr, unsigned long value)
{
struct vcpu_svm *svm = to_svm(vcpu);
- *exception = 0;
-
switch (dr) {
case 0 ... 3:
vcpu-arch.db[dr] = value;
if (!(vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP))
vcpu-arch.eff_db[dr] = value;
- return;
- case 4 ... 5:
- if (vcpu-arch.cr4 X86_CR4_DE)
- *exception = UD_VECTOR;
- return;
+ break;
+ case 4:
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE))
+ return EMULATE_FAIL; /* will re-inject UD */
+ /* fall through */
case 6:
- if (value 0xULL) {
- *exception = GP_VECTOR;
- return;
- }
vcpu-arch.dr6 = (value DR6_VOLATILE) | DR6_FIXED_1;
- return;
+ break;
+ case 5:
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE))
+ return EMULATE_FAIL; /* will re-inject UD */
+ /* fall through */
case 7:
- if (value 0xULL) {
- *exception = GP_VECTOR;
- return;
- }
vcpu-arch.dr7 = (value DR7_VOLATILE) | DR7_FIXED_1;
if (!(vcpu-guest_debug
[PATCH 5/5] KVM: SVM: Trap all debug register accesses
To enable proper debug register emulation under all conditions, trap
access to all DR0..7. This may be optimized later on.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/svm.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4295dfc..a281368 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -554,13 +554,19 @@ static void init_vmcb(struct vcpu_svm *svm)
control-intercept_dr_read =INTERCEPT_DR0_MASK |
INTERCEPT_DR1_MASK |
INTERCEPT_DR2_MASK |
- INTERCEPT_DR3_MASK;
+ INTERCEPT_DR3_MASK |
+ INTERCEPT_DR4_MASK |
+ INTERCEPT_DR5_MASK |
+ INTERCEPT_DR6_MASK |
+ INTERCEPT_DR7_MASK;
control-intercept_dr_write = INTERCEPT_DR0_MASK |
INTERCEPT_DR1_MASK |
INTERCEPT_DR2_MASK |
INTERCEPT_DR3_MASK |
+ INTERCEPT_DR4_MASK |
INTERCEPT_DR5_MASK |
+ INTERCEPT_DR6_MASK |
INTERCEPT_DR7_MASK;
control-intercept_exceptions = (1 PF_VECTOR) |
@@ -2319,11 +2325,17 @@ static int (*svm_exit_handlers[])(struct vcpu_svm *svm)
= {
[SVM_EXIT_READ_DR1] = emulate_on_interception,
[SVM_EXIT_READ_DR2] = emulate_on_interception,
[SVM_EXIT_READ_DR3] = emulate_on_interception,
+ [SVM_EXIT_READ_DR4] = emulate_on_interception,
+ [SVM_EXIT_READ_DR5] = emulate_on_interception,
+ [SVM_EXIT_READ_DR6] = emulate_on_interception,
+ [SVM_EXIT_READ_DR7] = emulate_on_interception,
[SVM_EXIT_WRITE_DR0]= emulate_on_interception,
[SVM_EXIT_WRITE_DR1]= emulate_on_interception,
[SVM_EXIT_WRITE_DR2]= emulate_on_interception,
[SVM_EXIT_WRITE_DR3]= emulate_on_interception,
+ [SVM_EXIT_WRITE_DR4]= emulate_on_interception,
[SVM_EXIT_WRITE_DR5]= emulate_on_interception,
+ [SVM_EXIT_WRITE_DR6]= emulate_on_interception,
[SVM_EXIT_WRITE_DR7]= emulate_on_interception,
[SVM_EXIT_EXCP_BASE + DB_VECTOR]= db_interception,
[SVM_EXIT_EXCP_BASE + BP_VECTOR]= bp_interception,
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] KVM: VMX: Clean up DR6 emulation
As we trap all debug register accesses, we do not need to switch real
DR6 at all. Clean up update_exception_bitmap at this chance, too.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/vmx.c | 23 ++-
1 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 834a8eb..75f1785 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -579,17 +579,12 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
{
u32 eb;
- eb = (1u PF_VECTOR) | (1u UD_VECTOR) | (1u MC_VECTOR)
- | (1u NM_VECTOR);
- /*
-* Unconditionally intercept #DB so we can maintain dr6 without
-* reading it every exit.
-*/
- eb |= 1u DB_VECTOR;
- if (vcpu-guest_debug KVM_GUESTDBG_ENABLE) {
- if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
- eb |= 1u BP_VECTOR;
- }
+ eb = (1u PF_VECTOR) | (1u UD_VECTOR) | (1u MC_VECTOR) |
+(1u NM_VECTOR) | (1u DB_VECTOR);
+ if ((vcpu-guest_debug
+(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
+ (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
+ eb |= 1u BP_VECTOR;
if (to_vmx(vcpu)-rmode.vm86_active)
eb = ~0;
if (enable_ept)
@@ -3781,9 +3776,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
*/
vmcs_writel(HOST_CR0, read_cr0());
- if (vcpu-arch.switch_db_regs)
- set_debugreg(vcpu-arch.dr6, 6);
-
asm(
/* Store host registers */
push %%Rdx; push %%Rbp;
@@ -3884,9 +3876,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
| (1 VCPU_EXREG_PDPTR));
vcpu-arch.regs_dirty = 0;
- if (vcpu-arch.switch_db_regs)
- get_debugreg(vcpu-arch.dr6, 6);
-
vmx-idt_vectoring_info = vmcs_read32(IDT_VECTORING_INFO_FIELD);
if (vmx-rmode.irq.pending)
fixup_rmode_irq(vmx);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bad leakage between virtual machines?
Jan Kiszka wrote: Jan Kiszka wrote: Tom Horsley wrote: On Fri, 15 Jan 2010 18:37:57 +0100 Jan Kiszka wrote: Tom Horsley wrote: I just submitted this fedora bug with lots of details: https://bugzilla.redhat.com/show_bug.cgi?id=555788 It sure seems to me like the contents of the debug address trap registers are leaking across virtual machines (at least for opterons on this motherboard :-). Are only AMD boxes affected, or did you also test on Intel? I haven't explicitly tested on Intel, but we did just see a compile on a guest on the Intel host also get the same Breakpoint/Trap error out of the blue, so it looks as if it does happen on intel as well as amd. OK, will have a look at your test application once time permits. Just did so with bleeding-edge kvm-kmod and qemu-kvm-0.12.1.2 on an Intel host. But nothing exciting happened. Are you sure that test on an Intel host was really an Intel? In your bug report you write the contrary. Anyway, will have my hands on an AMD box tomorrow and try to reproduce there. No success reproducing on AMD either. This time I'm using kvm-kmod-2.6.32.3 (so none of today's debug register patches applied) and qemu-kvm-0.12.1.2. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/12] Add handle page fault PV helper.
On 01/20/2010 02:02 AM, Gleb Natapov wrote: You can have the guest OS take an exception on a vector above 31 just fine; you just need it to tell the hypervisor which vector it, the OS, assigned for this purpose. VMX doesn't allow to inject hardware exception with vector greater then 31. SDM 3B section 23.2.1.3. OK, you're right. I had missed that... I presume it was done for implementation reasons. I can inject the event as HW interrupt on vector greater then 32 but not go through APIC so EOI will not be required. This sounds non-architectural and I am not sure kernel has entry point code for this kind of event, it has one for exception and one for interrupts that goes through __do_IRQ() which assumes that interrupts should be ACKed. You can also just emulate the state transition -- since you know you're dealing with a flat protected-mode or long-mode OS (and just make that a condition of enabling the feature) you don't have to deal with all the strange combinations of directions that an unrestricted x86 event can take. Since it's an exception, it is unconditional. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] qemu-kvm-0.12.2
qemu-kvm-0.12.2 is now available. This release is based on the upstream qemu 0.12.2, plus kvm-specific enhancements. Please see the original qemu 0.12.2 release announcement for details. This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32. Changes from qemu-kvm-0.12.1.2 Anthony Liguori (3): vnc: Fix artifacts in hextile decoding Update SeaBIOS to 0.5.1 Update version and changelog for release Aurelien Jarno (2): target-i386: Fix call im on x86_64 when executing 32-bit code loader: more ignores for rom intended to be loaded by the bios Avi Kivity (1): linuxboot: fix gdt address calculation Chris Wright (1): device assignment: default requires IOMMU Christoph Hellwig (1): dmg: fix -open failure Gerd Hoffmann (6): pc: add machine type for 0.12 roms: minor fixes and cleanups. fw_cfg: rom loader tweaks. roms: rework rom loading via fw pci: allow loading roms via fw_cfg. pc: add rombar to compat properties for pc-0.10 and pc-0.11 Gleb Natapov (1): remove pending exception on vcpu reset. Huang Ying (1): MCE: Fix bug of IA32_MCG_STATUS after system reset Jiri Denemark (1): Fix CPU topology initialization Kevin Wolf (1): osdep.c: Fix accept4 fallback Luiz Capitulino (2): QMP: Drop wrong assert() QMP: Don't free async event's 'data' Michael S. Tsirkin (2): e1000: fix init values for command register virtio-pci: thinko fix Michael Tokarev (1): Add missing newline at the end of options list Milan Plzik (1): Qemu's internal TFTP server breaks lock-step-iness of TFTP Roland Dreier (1): vmware_vga: Check cursor dimensions passed from guest to avoid buffer overflow Stefan Weil (1): pc-bios: Update README (SeaBIOS) Stefano Stabellini (1): vnc_refresh: return if vd-timer is NULL Thomas Horsten (1): Handle TFTP ERROR from client http://www.linux-kvm.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/12] Add handle page fault PV helper.
On 01/20/2010 04:00 AM, Avi Kivity wrote: On 01/20/2010 12:02 PM, Gleb Natapov wrote: I can inject the event as HW interrupt on vector greater then 32 but not go through APIC so EOI will not be required. This sounds non-architectural and I am not sure kernel has entry point code for this kind of event, it has one for exception and one for interrupts that goes through __do_IRQ() which assumes that interrupts should be ACKed. Further, we start to interact with the TPR; Linux doesn't use the TPR or cr8 but if it does one day we don't want it interfering with apf. I don't think the TPR would be involved unless you involve the APIC (which you absolutely don't want to do.) What I'm trying to figure out is if you could inject this vector as external interrupt and still have it deliver if IF=0, or if it would cause any other funnies. As that point, you do not want to go through the do_IRQ path but rather through your own exception vector entry point (it would be an entry point which doesn't get an error code, like #UD.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Jamie Lokier wrote: Anthony Liguori wrote: On 01/18/2010 10:45 AM, john cooper wrote: x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron) x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) I'm very much against having -cpu Nehalem. The whole point of this is to make things easier for a user and for most of the users I've encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,... When I saw that table just now, I had no idea whether Nehalem is newer and more advanced than Penryn, or the other way around. I also have no idea if Core i7 is newer than Core 2 Duo or not. I can appreciate the argument above, however the goal was choosing names with some basis in reality. These were recommended by our contacts within Intel, are used by VmWare to describe their similar cpu models, and arguably have fallen to defacto usage as evidenced by such sources as: http://en.wikipedia.org/wiki/Conroe_(microprocessor) http://en.wikipedia.org/wiki/Penryn_(microprocessor) http://en.wikipedia.org/wiki/Nehalem_(microarchitecture) I suspect whatever we choose of reasonable length as a model tag for -cpu some further detail is going to be required. That was the motivation to augment the table as above with an instance of a LCD for that associated class. I'm not a typical user: I know quite a lot about x86 architecture; I just haven't kept up to date enough to know the code/model names. Typical users will know less about them. Understood. One thought I had to further clarify what is going on under the hood was to dump the cpuid flags for each model as part of (or in addition to) the above table. But this seems a bit extreme and kvm itself can modify flags exported from qemu to a guest. -john -- john.coo...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Anthony Liguori wrote: On 01/19/2010 02:03 PM, Chris Wright wrote: * Anthony Liguori (anth...@codemonkey.ws) wrote: I'm very much against having -cpu Nehalem. The whole point of this is to make things easier for a user and for most of the users I've encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,... What name will these users know? FWIW, it makes sense to me as it is. Whatever is in /proc/cpuinfo. $ grep name /proc/cpuinfo model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz Which is detailing that exact cpu vs. the class of which it is a member. So are you suggesting to map all instances of processors called out in /proc/cpuinfo into one of the three defined models? We can certainly do that however I was looking for a more terse and simplified solution at this level while deferring more ornate mapping schemes to management tools. Still at the user facing CLI this doesn't strike me as the most friendly encoding of a -cpu name. -john -- john.coo...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Jamie Lokier wrote: john cooper wrote: As before a cpu feature 'check' option is added which warns when feature flags (either implicit in a cpu model or explicit on the command line) would have otherwise been quietly unavailable to a guest: # qemu-system-x86_64 ... -cpu Nehalem,check warning: host cpuid _0001 lacks requested flag 'sse4.2' [0x0010] warning: host cpuid _0001 lacks requested flag 'popcnt' [0x0080] That's a nice feature. Can we have a 'checkfail' option which refuses to run if a requested capability isn't available? Thanks. Certainly, others have requested the same. Let's resolve the issue at hand first. I foresee wanting to iterate over the models and pick the latest one which a host supports - on the grounds that you have done the hard work of ensuring it is a reasonably good performer, while probably working on another host of similar capability when a new host is made available. That's a fairly close use case to that of safe migration which was one of the primary motivations to identify the models being discussed. Although presentation and administration of such was considered the domain of management tools. -john -- john.coo...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
On Wed, Jan 20, 2010 at 03:09:53PM -0500, john cooper wrote: Anthony Liguori wrote: On 01/19/2010 02:03 PM, Chris Wright wrote: * Anthony Liguori (anth...@codemonkey.ws) wrote: I'm very much against having -cpu Nehalem. The whole point of this is to make things easier for a user and for most of the users I've encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,... What name will these users know? FWIW, it makes sense to me as it is. Whatever is in /proc/cpuinfo. $ grep name /proc/cpuinfo model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz Which is detailing that exact cpu vs. the class of which it is a member. So are you suggesting to map all instances of processors called out in /proc/cpuinfo into one of the three defined models? We can certainly do that however I was looking for a more terse and simplified solution at this level while deferring more ornate mapping schemes to management tools. Still at the user facing CLI this doesn't strike me as the most friendly encoding of a -cpu name. To be honest all possible naming schemes for '-cpu name' are just as unfriendly as each other. The only user friendly option is '-cpu host'. IMHO, we should just pick a concise naming scheme document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
On 01/20/2010 02:26 PM, Daniel P. Berrange wrote: To be honest all possible naming schemes for '-cpuname' are just as unfriendly as each other. The only user friendly option is '-cpu host'. IMHO, we should just pick a concise naming scheme document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner. IIUC, VMware uses Group A, Group B, etc. which is pretty close to saying Family 10h IMHO. Regards, Anthony Liguori Daniel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] qemu-kvm-0.12.2
Marcelo Tosatti wrote: qemu-kvm-0.12.2 is now available. This release is based on the upstream qemu 0.12.2, plus kvm-specific enhancements. Please see the original qemu 0.12.2 release announcement for details. Thank you Avi, Marcelo and all others, for the new release. On my side, I've updated the Debian packages on the usual place, http://www.corpit.ru/debian/tls/kvm/ , for both i386 and amd64. /mjt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add definitions for current cpu models..
On Monday 18 January 2010, john cooper wrote:
+.name = Conroe,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
that looks wrong -- what is model 2 actually?
+.stepping = 3,
+.features = PPRO_FEATURES |
+CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |/* note 1 */
+CPUID_PSE36,/* note 2 */
+.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_SSSE3,
+.ext2_features = (PPRO_FEATURES CPUID_EXT2_MASK) |
+CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.ext3_features = CPUID_EXT3_LAHF_LM,
+.xlevel = 0x800A,
+.model_id = Intel Celeron_4x0 (Conroe/Merom Class Core 2),
+},
Celeron_4x0 is a rather bad example, because it is based on the
single-core Conroe-L, which is family 6 / model 22 unlike all the dual-
and quad-core Merom/Conroe that are model 15.
+{
+.name = Penryn,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
+.stepping = 3,
+.features = PPRO_FEATURES |
+CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |/* note 1 */
+CPUID_PSE36,/* note 2 */
+.ext_features = CPUID_EXT_SSE3 |
+CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE41,
+.ext2_features = (PPRO_FEATURES CPUID_EXT2_MASK) |
+CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.ext3_features = CPUID_EXT3_LAHF_LM,
+.xlevel = 0x800A,
+.model_id = Intel Core 2 Duo P9xxx (Penryn Class Core 2),
+},
This would be model 23 for Penryn-class Xeon/Core/Pentium/Celeron processors
without L3 cache.
+{
+.name = Nehalem,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
+.stepping = 3,
+.features = PPRO_FEATURES |
+CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |/* note 1 */
+CPUID_PSE36,/* note 2 */
+.ext_features = CPUID_EXT_SSE3 |
+CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE41 |
+CPUID_EXT_SSE42 | CPUID_EXT_POPCNT,
+.ext2_features = (PPRO_FEATURES CPUID_EXT2_MASK) |
+CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.ext3_features = CPUID_EXT3_LAHF_LM,
+.xlevel = 0x800A,
+.model_id = Intel Core i7 9xx (Nehalem Class Core i7),
+},
Apparently, not all the i7-9xx CPUs are Nehalem, the i7-980X is supposed
to be Westmere, which has more features.
Because of the complexity, I'd recommend passing down the *model* number
of the emulated CPU, the interesting Intel ones (those supported by KVM) being:
15-6: CedarMill/Presler/Dempsey/Tulsa (Pentium 4/Pentium D/Xeon 50xx/Xeon 71xx)
6-14: Yonah/Sossaman (Celeron M4xx, Core Solo/Duo, Pentium Dual-Core T1000,
Xeon ULV)
6-15: Merom/Conroe/Kentsfield/Woodcrest/Clovertown/Tigerton
(Celeron M5xx/E1xxx/T1xxx, Pentium T2xxx/T3xxx/E2xxx,Core 2 Solo U2xxx,
Core 2 Duo E4xxx/E6xxx/Q6xxx/T5xxx/T7xxx/L7xxx/U7xxx/SP7xxx,
Xeon 30xx/32xx/51xx/52xx/72xx/73xx)
6-22: Penryn/Wolfdale/Yorkfield/Harpertown (Celeron 7xx/9xx/SU2xxx/T3xxx/E3xxx,
Pentium T4xxx/SU2xxx/SU4xxx/E5xxx/E6xxx, Core 2 Solo SU3xxx,
Core 2 Duo P/SU/T6xxx/x8xxx/x9xxx,
Xeon 31xx/33xx/52xx/54xx)
6-26: Gainestown/Bloomfield (Xeon 35xx/55xx, Core i7-9xx)
6-28: Atom
6-29: Dunnington (Xeon 74xx)
6-30: Lynnfield/Clarksfield/JasperForest (Xeon 34xx, Core i7-8xx, Core i7-xxxQM,
Core i5-7xx)
6-37: Arrandale/Clarkdale (Dual-Core Core i3/i5/i7)
6-44: Gulftown (six-core)
Arnd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document it. Given
they are all equally unfriendly, the one that has consistency with vmware
naming seems like a mild winner.
Heh, I completely agree, and was just saying the same thing to John
earlier today. May as well be -cpu {foo,bar,baz} since the meaning for
those command line options must be well-documented in the man page.
This is from an EVC kb article[1]:
ESX/ESXi 4.0 supports the following EVC modes:
* AMD Opteron™ Generation 1 (Rev. E)
* AMD Opteron™ Generation 2 (Rev. F)
* AMD Opteron™ Generation 3 (Greyhound)
* Intel® Xeon® Core2 (Merom)
* Intel® Xeon® 45nm Core2 (Penryn)
* Intel® Xeon® Core i7 (Nehalem)
Not that different from John's proposal.
thanks,
-chris
[1] http://kb.vmware.com/kb/1005764
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document it. Given
they are all equally unfriendly, the one that has consistency with vmware
naming seems like a mild winner.
Heh, I completely agree, and was just saying the same thing to John
earlier today. May as well be -cpu {foo,bar,baz} since the meaning for
those command line options must be well-documented in the man page.
I can appreciate the concern of wanting to get this
as correct as possible. But ultimately we just
need three unique tags which ideally have some relation
to their associated architectures. The diatribes
available from /proc/cpuinfo while generally accurate
don't really offer any more of a clue to the model
group, and in their unmodified form are rather unwieldy
as command line flags.
This is from an EVC kb article[1]:
Here is a pointer to a more detailed version:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1003212
We probably should also add an option to dump out the
full set of qemu-side cpuid flags for the benefit of
users and upper level tools.
-john
--
john.coo...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] qemu-kvm-0.12.2
On Thu, Jan 21, 2010 at 11:43 AM, Michael Tokarev m...@tls.msk.ru wrote: Marcelo Tosatti wrote: qemu-kvm-0.12.2 is now available. This release is based on the upstream qemu 0.12.2, plus kvm-specific enhancements. Please see the original qemu 0.12.2 release announcement for details. Thank you Avi, Marcelo and all others, for the new release. On my side, I've updated the Debian packages on the usual place, http://www.corpit.ru/debian/tls/kvm/ , for both i386 and amd64. I have uploaded the qemu-kvm_0.12.2-0ubuntu1 Ubuntu package to the Lucid (development) archive. It's building now, should be published within the hour. :-Dustin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2936094 ] BUG: kvm_dirty_pages_log_enable_slot: invalid parameters
Bugs item #2936094, was opened at 2010-01-21 11:07 Message generated for change (Tracker Item Submitted) made by kolobrod You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2936094group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergey _ (kolobrod) Assigned to: Nobody/Anonymous (nobody) Summary: BUG: kvm_dirty_pages_log_enable_slot: invalid parameters Initial Comment: Upgraded userspace to qemu-kvm-0.12.2. # uname -srvmpio Linux 2.6.31-gentoo-r6 #1 SMP Fri Dec 18 11:43:50 YEKT 2009 x86_64 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux # emerge qemu-kvm -pv ... [ebuild R ] app-emulation/qemu-kvm-0.12.2 USE=aio alsa curl gnutls ncurses sdl -bluetooth -esd -fdt -hardened -kvm-trace -pulseaudio -sasl -vde QEMU_SOFTMMU_TARGETS=x86_64 -arm -cris -i386 -m68k -microblaze -mips -mips64 -mips64el -mipsel -ppc -ppc64 -ppcemb -sh4 -sh4eb -sparc -sparc64 QEMU_USER_TARGETS=x86_64 -alpha -arm -armeb -cris -i386 -m68k -microblaze -mips -mipsel -ppc -ppc64 -ppc64abi32 -sh4 -sh4eb -sparc -sparc32plus -sparc64 0 kB ... I'm starting vm with kvm -cpu qemu64 -tdf -drive file=/home/sergey/virtual/winsrv2008_1.img,if=virtio,media=disk,boot=on -net nic,model=virtio -net tap,ifname=testtuntap,script=no,downscript=no -m 384 -usbdevice tablet -vga std -runas sergey Have got this on startup: # BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters It works yet, but messages looks bad. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2936094group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a
[Autotest PATCH] KVM-test: subtest migrate: Use 'wait_for_login' to log into migrated guest
Using 'wait_for' for logging into migrated guest repeats the work of 'wait_for_login' which exists already. We just need to change the name of 'dest_vm'. Signed-off-by: Yolkfull Chow yz...@redhat.com --- client/tests/kvm/kvm_test_utils.py |1 + client/tests/kvm/tests/migration.py |7 ++- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/client/tests/kvm/kvm_test_utils.py b/client/tests/kvm/kvm_test_utils.py index 02ec0cf..13af8e1 100644 --- a/client/tests/kvm/kvm_test_utils.py +++ b/client/tests/kvm/kvm_test_utils.py @@ -135,6 +135,7 @@ def migrate(vm, env=None): # Clone the source VM and ask the clone to wait for incoming migration dest_vm = vm.clone() +dest_vm.name = migrated_guest dest_vm.create(for_migration=True) try: diff --git a/client/tests/kvm/tests/migration.py b/client/tests/kvm/tests/migration.py index b8f171c..b65064b 100644 --- a/client/tests/kvm/tests/migration.py +++ b/client/tests/kvm/tests/migration.py @@ -46,11 +46,8 @@ def run_migration(test, params, env): dest_vm = kvm_test_utils.migrate(vm, env) # Log into the guest again -logging.info(Logging into guest after migration...) -session2 = kvm_utils.wait_for(dest_vm.remote_login, 30, 0, 2) -if not session2: -raise error.TestFail(Could not log into guest after migration) -logging.info(Logged in after migration) +session2 = kvm_test_utils.wait_for_login(dest_vm, timeout=30, start=0, + step=2) # Make sure the background process is still running if session2.get_command_status(check_command, timeout=30) != 0: -- 1.6.6 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] kvmppc/e500: Add register l1csr0 emulation
Latest kernel start to access l1csr0 to contron L1.
We just tell guest no operation is on going.
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm_e500.h |1 +
arch/powerpc/kvm/e500_emulate.c |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_e500.h
b/arch/powerpc/include/asm/kvm_e500.h
index 9d497ce..569dfd3 100644
--- a/arch/powerpc/include/asm/kvm_e500.h
+++ b/arch/powerpc/include/asm/kvm_e500.h
@@ -52,6 +52,7 @@ struct kvmppc_vcpu_e500 {
u32 mas5;
u32 mas6;
u32 mas7;
+ u32 l1csr0;
u32 l1csr1;
u32 hid0;
u32 hid1;
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 7644f7a..95f8ec8 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -99,6 +99,10 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int
sprn, int rs)
vcpu_e500-mas6 = spr_val; break;
case SPRN_MAS7:
vcpu_e500-mas7 = spr_val; break;
+ case SPRN_L1CSR0:
+ vcpu_e500-l1csr0 = spr_val;
+ vcpu_e500-l1csr0 = ~(L1CSR0_DCFI | L1CSR0_CLFC);
+ break;
case SPRN_L1CSR1:
vcpu_e500-l1csr1 = spr_val; break;
case SPRN_HID0:
@@ -179,6 +183,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
break;
}
+ case SPRN_L1CSR0:
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500-l1csr0); break;
case SPRN_L1CSR1:
kvmppc_set_gpr(vcpu, rt, vcpu_e500-l1csr1); break;
case SPRN_HID0:
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] kvmppc/e500:
These patches fix current e500 break. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] kvmppc/e500: fix tlbcfg emulation
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/kvm/e500_emulate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 95f8ec8..97337dd 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -165,7 +165,7 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
case SPRN_TLB0CFG:
{
- ulong tmp = SPRN_TLB0CFG;
+ ulong tmp = mfspr(SPRN_TLB0CFG);
tmp = ~0xfffUL;
tmp |= vcpu_e500-guest_tlb_size[0];
@@ -175,7 +175,7 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
case SPRN_TLB1CFG:
{
- ulong tmp = SPRN_TLB1CFG;
+ ulong tmp = mfspr(SPRN_TLB1CFG);
tmp = ~0xfffUL;
tmp |= vcpu_e500-guest_tlb_size[1];
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] kvmppc/e500:
On 01/20/2010 10:03 AM, Liu Yu wrote: These patches fix current e500 break. Please copy Marcelo (mtosa...@redhat.com) on patches too, I don't think he reads kvm-...@. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] kvmppc/e500: Add PVR/PIR init for E500
On 20.01.2010, at 09:03, Liu Yu wrote: Signed-off-by: Liu Yu yu@freescale.com --- arch/powerpc/kvm/e500.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c index 64949ee..fd3683d 100644 --- a/arch/powerpc/kvm/e500.c +++ b/arch/powerpc/kvm/e500.c @@ -60,6 +60,10 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu) kvmppc_e500_tlb_setup(vcpu_e500); + /* Registers init */ + vcpu-arch.pvr = mfspr(SPRN_PVR); + vcpu-vcpu_id = mfspr(SPRN_PIR); Is this correct? IIUC this should be the number of the vcpu. So if you virtualize a 2-core system, but both vcpu init functions run on core 1, this will break, right? Alex-- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] kvmppc/e500: fix tlbcfg emulation
On 20.01.2010, at 09:03, Liu Yu wrote:
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/kvm/e500_emulate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 95f8ec8..97337dd 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -165,7 +165,7 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
case SPRN_TLB0CFG:
{
- ulong tmp = SPRN_TLB0CFG;
+ ulong tmp = mfspr(SPRN_TLB0CFG);
Does this SPR value change? I hope not :-). If not, better read it once on init
and then use it from there.
Alex--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] kvmppc/e500: fix tlbcfg emulation
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Wednesday, January 20, 2010 6:47 PM
To: Liu Yu-B13201
Cc: kvm-ppc@vger.kernel.org; a...@redhat.com; hol...@penguinppc.org
Subject: Re: [PATCH 3/3] kvmppc/e500: fix tlbcfg emulation
Importance: High
On 20.01.2010, at 09:03, Liu Yu wrote:
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/kvm/e500_emulate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_emulate.c
b/arch/powerpc/kvm/e500_emulate.c
index 95f8ec8..97337dd 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -165,7 +165,7 @@ int kvmppc_core_emulate_mfspr(struct
kvm_vcpu *vcpu, int sprn, int rt)
case SPRN_TLB0CFG:
{
- ulong tmp = SPRN_TLB0CFG;
+ ulong tmp = mfspr(SPRN_TLB0CFG);
Does this SPR value change? I hope not :-). If not, better
read it once on init and then use it from there.
Out of curiousity. Does read it once in order to get better performance?
If yes, I think read from register is faster than read from mem.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] kvmppc/e500: Add PVR/PIR init for E500
-Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Wednesday, January 20, 2010 6:45 PM To: Liu Yu-B13201 Cc: kvm-ppc@vger.kernel.org; a...@redhat.com; hol...@penguinppc.org Subject: Re: [PATCH 2/3] kvmppc/e500: Add PVR/PIR init for E500 Importance: High On 20.01.2010, at 09:03, Liu Yu wrote: Signed-off-by: Liu Yu yu@freescale.com --- arch/powerpc/kvm/e500.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c index 64949ee..fd3683d 100644 --- a/arch/powerpc/kvm/e500.c +++ b/arch/powerpc/kvm/e500.c @@ -60,6 +60,10 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu) kvmppc_e500_tlb_setup(vcpu_e500); + /* Registers init */ + vcpu-arch.pvr = mfspr(SPRN_PVR); + vcpu-vcpu_id = mfspr(SPRN_PIR); Is this correct? IIUC this should be the number of the vcpu. So if you virtualize a 2-core system, but both vcpu init functions run on core 1, this will break, right? Since kvm booke doesn't support more than 1 core virtualization. Can we put a comment here for now? -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
