Re: kvm88 compile errors with 2.6.31.1
Hi all,
a late response of my part, but I got it partially working under
slackware 13.0 with the qemu-kvm-0.11.0.tar.gz (it compiles now without
errors.)
When I start my virtual machine in *windowed mode* it boots fine,It
installs the OS I want but everything is black around the windowed
screen, it seems like it started up in full screen but minimized ?
I can't access my KDE 4 desktop anymore, switching with the rebooting
the VM or closing it is impossible, I have to reboot my whole system. :-/
Help would be appreciated.
# uname -a
Linux r2d2 2.6.31.5 #1 SMP Wed Oct 28 12:10:47 CET 2009 x86_64 Intel(R)
Core(TM)2 Duo CPU P8400 @ 2.26GHz GenuineIntel GNU/Linux
I used the following to boot it (selfmade rc script:
source vars.sh (containing the variables)
/sbin/modprobe kvm_intel
/sbin/modprobe kvm
vm_start() {
ARGS=-hda $IMG \
-cdrom $CD \
-boot d \
-m $MEM \
-smp $CPU \
-localtime \
-no-acpi \
-no-reboot \
-pidfile $PID \
-full-screen \
-k nl-be
Michael Tokarev wrote:
Jorge Lucángeli Obes wrote:
2009/10/21 Michael Tokarev m...@tls.msk.ru:
Jorge Lucángeli Obes wrote:
[]
See this thread:
http://www.mail-archive.com/kvm@vger.kernel.org/msg22775.html
I believe the patches have already been applied, but there have not
been any releases since then.
qemu-kvm-0.11.0 is out for a long time.
It's true, I was actually refering to the kvm-XX snapshots. Does
qemu-kvm-0.11.0 include Jan's patches? I figured they would be on the
kvm-kmod side.
2.6.31 kernel includes more recent bits than kvm-kmod-88.. ;)
/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
[patch] add some unlocks on error paths irq_comm.c
There were a couple unlocks missing. They were found by smatch static
checker. Compile tested.
regards,
dan carpenter
Signed-off-by: Dan Carpenter erro...@gmail.com
--- orig/virt/kvm/irq_comm.c2009-11-08 19:00:50.0 +0200
+++ devel/virt/kvm/irq_comm.c 2009-11-08 19:04:45.0 +0200
@@ -209,6 +209,7 @@
sizeof(kvm-arch.irq_sources_bitmap));
if (irq_source_id = sizeof(kvm-arch.irq_sources_bitmap)) {
+ mutex_unlock(kvm-irq_lock);
printk(KERN_WARNING kvm: exhaust allocatable IRQ sources!\n);
return -EFAULT;
}
@@ -229,6 +230,7 @@
mutex_lock(kvm-irq_lock);
if (irq_source_id 0 ||
irq_source_id = sizeof(kvm-arch.irq_sources_bitmap)) {
+ mutex_unlock(kvm-irq_lock);
printk(KERN_ERR kvm: IRQ source ID out of range!\n);
return;
}
--
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: Doubt on KVM-88 vulnerabilities
On 11/08/2009 08:42 PM, Daniel Bareiro wrote: Hi all! I'm using KVM-88 compiled by myself from the source code provided by the official site of the project. Is this version of KVM vulnerable to the mentioned thing in the DSA-1907-1 [1]? Yes. In such case, there is some published patch that can be applied or some new version that solves this? I recommend to use distro-provided modules (or kernel.org kernels within their support period) for production use. This ensures you get security and stability fixes. kvm-89 will fix these issues, but as it's a development snapshot, may introduce new issues. -- 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 2/4] KVM: Add unified KVM_GET/SET_VCPU_STATE IOCTL
On 11/02/2009 06:20 PM, Jan Kiszka wrote:
Add a new IOCTL pair to retrieve or set the VCPU state in one chunk.
More precisely, the IOCTL is able to process a list of substates to be
read or written. This list is easily extensible without breaking the
existing ABI, thus we will no longer have to add new IOCTLs when we
discover a missing VCPU state field or want to support new hardware
features.
I'm having some second thoughts about this.
What does the new API buy us? Instead of declaring two new ioctls for
new/fixed substates, we only have to declare one. We still have the
capability check. We still have to declare a structure.
It's true that the internals are currently a mess. We can fix that with
a table-driven approach:
static struct kvm_state_ioctl state_ioctls[] = {
{
.get_ioctl = KVM_GET_FPU,
.set_ioctl = KVM_SET_FPU,
.get = kvm_get_fpu,
.set = kvm_set_fpu,
.size = sizeof(struct kvm_fpu), /* 0 for variable-size state */
},
};
(btw, the new stuff would also benefit from this).
So, what's the real justification for the new ABI?
Jan, my apologies for raising this at such a very late stage in the
review, after all the nits have been satisfactorily addressed. But I
want to make sure we don't bloat the interface without very good reasons.
--
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 1/4] KVM: Reorder IOCTLs in main kvm.h
On 11/02/2009 06:20 PM, Jan Kiszka wrote: Obviously, people tend to extend this header at the bottom - more or less blindly. Ensure that deprecated stuff gets its own corner again by moving things to the top. Also add some comments and reindent IOCTLs to make them more readable and reduce the risk of number collisions. Applied, thanks. -- 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: Doubt on KVM-88 vulnerabilities
Avi Kivity wrote: I recommend to use distro-provided modules (or kernel.org kernels within their support period) for production use. This ensures you get security and stability fixes. kvm-89 will fix these issues, but as it's a development snapshot, may introduce new issues. This is interesting. I prefer compiling from source especially for upgrading KVM on production systems, because then I do not need to upgrade the kernel (may introduce new stability issues on very new kernels) or the distro (may introduce LOTS of new changes and stability issues on production sytems). KVM is newer and evolves more rapidly than the kernel so it is more beneficial to upgrade KVM than the rest of the kernel or distro However for compiling from source I would need to know which versions of KVM are stable and which are not. I see the 89 you tell about, is not released yet: http://sourceforge.net/projects/kvm/files/ So did you mean that 89 is not yet for production use or will never be for production use? Are there versions number which are stabilization versions and others which are development, or they are all equal? You know it would be great if the KVM versions would be versioned like the kernels, so that we could have kvm version 86.1, 86.2, 86.3 which would apply only the bug fixes and not new stuff which might be risky (i.e. no speed optimizations) so one willing to upgrade a production system could choose a somewhat older version with a higher bugfix version number. In the past I chose the kvm-86 which had been just released (i.e. visible in http://sourceforge.net/projects/kvm/files/ ) but there was a bug on the CPU detection causing the message This kernel requires an x86-64 CPU, but only detected an i686 CPU. \n Unable to boot - please use a kernel appropriate for your CPU.. I had to manually find and apply the patch http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=8fa3b3ce6e . Luckily this bug was discussed somewhere so I could find the patch. Summing up, it would be great to have some maintained kvm versions... BTW I do not know what are kvm-kmod's or qemu-kvm's downloadable from http://sourceforge.net/projects/kvm/files/ : I always compile the kvm from source. Are those the solution to my problem? Where can I find info about the difference between the three? Thank you -- 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: [PATCHv9 3/3] vhost_net: a kernel-level virtio server
On Tue, Nov 10, 2009 at 01:49:09PM +1030, Rusty Russell wrote: One fix: vhost: fix TUN=m VHOST_NET=y drivers/built-in.o: In function `get_tun_socket': net.c:(.text+0x15436e): undefined reference to `tun_get_socket' Signed-off-by: Rusty Russell ru...@rustcorp.com.au --- drivers/vhost/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig --- a/drivers/vhost/Kconfig +++ b/drivers/vhost/Kconfig @@ -1,6 +1,6 @@ config VHOST_NET tristate Host kernel accelerator for virtio net (EXPERIMENTAL) - depends on NET EVENTFD EXPERIMENTAL + depends on NET EVENTFD TUN EXPERIMENTAL ---help--- This kernel module can be loaded in host kernel to accelerate guest networking with virtio_net. Not to be confused with virtio_net In fact, vhost can be built with TUN=n VHOST_NET=y as well (tun_get_socket is stubbed out in that case). So I think this is better (it looks strange until you realize that for tristate variables boolean logic math does not apply): --- From: Michael S. Tsirkin m...@redhat.com Subject: vhost: fix TUN=m VHOST_NET=y drivers/built-in.o: In function `get_tun_socket': net.c:(.text+0x15436e): undefined reference to `tun_get_socket' If tun is a module, vhost must be a module, too. If tun is built-in or disabled, vhost can be built-in. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig index 9f409f4..9e93553 100644 --- a/drivers/vhost/Kconfig +++ b/drivers/vhost/Kconfig @@ -1,6 +1,6 @@ config VHOST_NET tristate Host kernel accelerator for virtio net (EXPERIMENTAL) - depends on NET EVENTFD EXPERIMENTAL + depends on NET EVENTFD (TUN || !TUN) EXPERIMENTAL ---help--- This kernel module can be loaded in host kernel to accelerate guest networking with virtio_net. Not to be confused with virtio_net -- 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 v3 2/4] KVM: Add unified KVM_GET/SET_VCPU_STATE IOCTL
Avi Kivity wrote:
On 11/02/2009 06:20 PM, Jan Kiszka wrote:
Add a new IOCTL pair to retrieve or set the VCPU state in one chunk.
More precisely, the IOCTL is able to process a list of substates to be
read or written. This list is easily extensible without breaking the
existing ABI, thus we will no longer have to add new IOCTLs when we
discover a missing VCPU state field or want to support new hardware
features.
I'm having some second thoughts about this.
What does the new API buy us? Instead of declaring two new ioctls for
new/fixed substates, we only have to declare one. We still have the
capability check. We still have to declare a structure.
Right, we still need CAPs to protect us against undefined types. So
KVM_CHECK_VCPU_STATES is actually pointless - well, someone asked for it...
It's true that the internals are currently a mess. We can fix that with
a table-driven approach:
static struct kvm_state_ioctl state_ioctls[] = {
{
.get_ioctl = KVM_GET_FPU,
.set_ioctl = KVM_SET_FPU,
.get = kvm_get_fpu,
.set = kvm_set_fpu,
.size = sizeof(struct kvm_fpu), /* 0 for variable-size state */
Even a variable-sized state has a fixed-size header. The handlers would
have to deal with this, or we would need to define which field in the
header holds the extension size, and what is its multiplier.
},
};
(btw, the new stuff would also benefit from this).
Right.
So, what's the real justification for the new ABI?
The remaining differences are:
- single kernel call possible
- slightly higher regularity (the IOCTL space is rather chaotic)
Jan, my apologies for raising this at such a very late stage in the
review, after all the nits have been satisfactorily addressed. But I
want to make sure we don't bloat the interface without very good reasons.
I think we came from the idea: Let's have one new IOCTL that will fit
it all - now and then. That's obviously not cheaply achievable. So the
valid question is what our extension concept of the future should be,
the existing multi-IOCTL approach or the substates? I only have a slight
bias towards the latter but the strong wish to achieve to a final decision.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
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: Doubt on KVM-88 vulnerabilities
Asdo wrote: Avi Kivity wrote: I recommend to use distro-provided modules (or kernel.org kernels within their support period) for production use. This ensures you get security and stability fixes. kvm-89 will fix these issues, but as it's a development snapshot, may introduce new issues. This is interesting. I prefer compiling from source especially for upgrading KVM on production systems, because then I do not need to upgrade the kernel (may introduce new stability issues on very new kernels) or the distro (may introduce LOTS of new changes and stability issues on production sytems). KVM is newer and evolves more rapidly than the kernel so it is more beneficial to upgrade KVM than the rest of the kernel or distro There's no need to compile kvm _modules_ if you're using recent-enough kernel. I _fail_ to see why people are still using older and buggy modules from kvm-88 with kernels =2.6.30 where these modules are more recent and with bugfixes. But that's entirely different point. However for compiling from source I would need to know which versions of KVM are stable and which are not. qemu-kvm-n.nn.n are stable releases. First stable release (0.10) already contained the fixes you mentioned. They're versioned exactly like kernel - 0.10.0, 0.10.1, ..., 0.10.6 like 2.6.27 .. 2.6.26.36 or what it is now. Current qemu-kvm is 0.11.0. I see the 89 you tell about, is not released yet: http://sourceforge.net/projects/kvm/files/ So did you mean that 89 is not yet for production use or will never be for production use? kvm-nn never was and never will be for production. They always has been and always will be nothing more than development snapshots. And the whole thing has been asked and answered numerous times here and elsewhere. /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 v3 2/4] KVM: Add unified KVM_GET/SET_VCPU_STATE IOCTL
On 11/10/2009 02:03 PM, Jan Kiszka wrote:
I'm having some second thoughts about this.
What does the new API buy us? Instead of declaring two new ioctls for
new/fixed substates, we only have to declare one. We still have the
capability check. We still have to declare a structure.
Right, we still need CAPs to protect us against undefined types. So
KVM_CHECK_VCPU_STATES is actually pointless - well, someone asked for it...
It's not pointless - you can do a compile-time check for
KVM_VCPU_STATE_... and a runtime check using KVM_CHECK_VCPU_STATES. But
it does duplicate the existing KVM_CAP_ functionality.
It's true that the internals are currently a mess. We can fix that with
a table-driven approach:
static struct kvm_state_ioctl state_ioctls[] = {
{
.get_ioctl = KVM_GET_FPU,
.set_ioctl = KVM_SET_FPU,
.get = kvm_get_fpu,
.set = kvm_set_fpu,
.size = sizeof(struct kvm_fpu), /* 0 for variable-size state */
Even a variable-sized state has a fixed-size header. The handlers would
have to deal with this, or we would need to define which field in the
header holds the extension size, and what is its multiplier.
Since we have very few variable-size states, and their number is
unlikely to increase, ad-hoc handling should be sufficient.
So, what's the real justification for the new ABI?
The remaining differences are:
- single kernel call possible
Is there a real advantage in this? It's not a high performance call,
typically only called during save/restore, reset, and for vmware's
wonderful ioport interface.
- slightly higher regularity (the IOCTL space is rather chaotic)
But still, actually handling the state is not regular either on the
userspace or kernel side.
Jan, my apologies for raising this at such a very late stage in the
review, after all the nits have been satisfactorily addressed. But I
want to make sure we don't bloat the interface without very good reasons.
I think we came from the idea: Let's have one new IOCTL that will fit
it all - now and then. That's obviously not cheaply achievable. So the
valid question is what our extension concept of the future should be,
the existing multi-IOCTL approach or the substates? I only have a slight
bias towards the latter but the strong wish to achieve to a final decision.
It would have been better to start from substates in the first place,
since there is less duplication: instead of 2 x NR_STATES ioctls, we
define 2 ioctls + NR_STATES defines. It's more regular and less chance
for errors (like misspelling _IOR/_IOW).
But given that we already do have the old interface, perhaps it's best
to stick with it and concentrate on improving the internals.
--
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] Seperate smp from extra_params and add into default VM params
I am OK with it, applied, thanks! On Tue, Nov 3, 2009 at 4:27 AM, Yolkfull Chow yz...@redhat.com wrote: We may need leave smp as standalone parameter of VM. Reasons I can proposal: 1) memory is a standalone parameter, so is smp 2) smp parameter is needed in some test case, say VM params_verify Signed-off-by: Yolkfull Chow yz...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample | 3 ++- client/tests/kvm/kvm_vm.py | 4 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 573206c..c16b615 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -18,6 +18,7 @@ kill_unresponsive_vms = yes # Some default VM params qemu_binary = qemu qemu_img_binary = qemu-img +smp = 1 mem = 512 image_size = 10G shell_port = 22 @@ -751,7 +752,7 @@ variants: - @up: no autotest.npb - smp2: - extra_params += -smp 2 + smp = 2 used_cpus = 2 stress_boot: used_cpus = 10 timedrift.with_load: used_cpus = 100 diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py index ee6796b..0b7a81e 100755 --- a/client/tests/kvm/kvm_vm.py +++ b/client/tests/kvm/kvm_vm.py @@ -261,6 +261,10 @@ class VM: if mem: qemu_cmd += -m %s % mem + smp = params.get(smp) + if smp: + qemu_cmd += -smp %s % smp + iso = params.get(cdrom) if iso: iso = kvm_utils.get_path(root_dir, iso) -- 1.6.5.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 -- Lucas -- 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 2/4] KVM: Add unified KVM_GET/SET_VCPU_STATE IOCTL
Avi Kivity wrote:
On 11/10/2009 02:03 PM, Jan Kiszka wrote:
I'm having some second thoughts about this.
What does the new API buy us? Instead of declaring two new ioctls for
new/fixed substates, we only have to declare one. We still have the
capability check. We still have to declare a structure.
Right, we still need CAPs to protect us against undefined types. So
KVM_CHECK_VCPU_STATES is actually pointless - well, someone asked for it...
It's not pointless - you can do a compile-time check for
KVM_VCPU_STATE_... and a runtime check using KVM_CHECK_VCPU_STATES. But
it does duplicate the existing KVM_CAP_ functionality.
It's redundant, therefore I considered it pointless.
It's true that the internals are currently a mess. We can fix that with
a table-driven approach:
static struct kvm_state_ioctl state_ioctls[] = {
{
.get_ioctl = KVM_GET_FPU,
.set_ioctl = KVM_SET_FPU,
.get = kvm_get_fpu,
.set = kvm_set_fpu,
.size = sizeof(struct kvm_fpu), /* 0 for variable-size state */
Even a variable-sized state has a fixed-size header. The handlers would
have to deal with this, or we would need to define which field in the
header holds the extension size, and what is its multiplier.
Since we have very few variable-size states, and their number is
unlikely to increase, ad-hoc handling should be sufficient.
Regarding CPU states, there is actually only the MSR interface.
So, what's the real justification for the new ABI?
The remaining differences are:
- single kernel call possible
Is there a real advantage in this? It's not a high performance call,
typically only called during save/restore, reset, and for vmware's
wonderful ioport interface.
And debugging. But, true, this is all fairly uncritical.
- slightly higher regularity (the IOCTL space is rather chaotic)
But still, actually handling the state is not regular either on the
userspace or kernel side.
Jan, my apologies for raising this at such a very late stage in the
review, after all the nits have been satisfactorily addressed. But I
want to make sure we don't bloat the interface without very good reasons.
I think we came from the idea: Let's have one new IOCTL that will fit
it all - now and then. That's obviously not cheaply achievable. So the
valid question is what our extension concept of the future should be,
the existing multi-IOCTL approach or the substates? I only have a slight
bias towards the latter but the strong wish to achieve to a final decision.
It would have been better to start from substates in the first place,
since there is less duplication: instead of 2 x NR_STATES ioctls, we
define 2 ioctls + NR_STATES defines. It's more regular and less chance
for errors (like misspelling _IOR/_IOW).
But given that we already do have the old interface, perhaps it's best
to stick with it and concentrate on improving the internals.
So the new roadmap shall be like this:
o Add KVM_X86_GET/SET_EVENT_STATES (instead of
KVM_X86_VCPU_STATE_EVENTS)
o Refactor in-kernel VCPU state IOCTLs to use table-driven dispatching
and shared argument passing
o Maybe refactor user space as well towards a table-driven state sync
(need to think about this a bit more)
Any other comments or does everyone agree?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
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 2/4] KVM: Add unified KVM_GET/SET_VCPU_STATE IOCTL
On 11/10/2009 03:22 PM, Jan Kiszka wrote: Since we have very few variable-size states, and their number is unlikely to increase, ad-hoc handling should be sufficient. Regarding CPU states, there is actually only the MSR interface. cpuid internal states too. So the new roadmap shall be like this: o Add KVM_X86_GET/SET_EVENT_STATES (instead of KVM_X86_VCPU_STATE_EVENTS) o Refactor in-kernel VCPU state IOCTLs to use table-driven dispatching and shared argument passing o Maybe refactor user space as well towards a table-driven state sync (need to think about this a bit more) Any other comments or does everyone agree? Looks good to me. These are all independent, of course. -- 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 2/4] KVM: Add unified KVM_GET/SET_VCPU_STATE IOCTL
Avi Kivity wrote: On 11/10/2009 03:22 PM, Jan Kiszka wrote: Since we have very few variable-size states, and their number is unlikely to increase, ad-hoc handling should be sufficient. Regarding CPU states, there is actually only the MSR interface. cpuid internal states too. Oh, yes. So the new roadmap shall be like this: o Add KVM_X86_GET/SET_EVENT_STATES (instead of KVM_X86_VCPU_STATE_EVENTS) o Refactor in-kernel VCPU state IOCTLs to use table-driven dispatching and shared argument passing o Maybe refactor user space as well towards a table-driven state sync (need to think about this a bit more) Any other comments or does everyone agree? Looks good to me. These are all independent, of course. Yep. The first one will come first and ASAP, should be easy to derive from existing series. The others have to wait a bit now. Jan -- Siemens AG, Corporate Technology, CT SE 2 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
buildbot failure in qemu-kvm on default_x86_64_out_of_tree
The Buildbot has detected a new failure of default_x86_64_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/87 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Avi Kivity a...@redhat.com BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on default_i386_out_of_tree
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/85 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Avi Kivity a...@redhat.com BUILD FAILED: failed compile sincerely, -The Buildbot -- 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: Doubt on KVM-88 vulnerabilities
Thanks for your reply, sorry to get you angry, but there are still things which are not clear to me. Please note that if you try to search kvm kvm-kmod kvm-qemu with google you will discover that basically nothing comes out telling you the differences between the three. Now searching within this mailing list I did find ONE thread that tells the thing http://www.spinics.net/lists/kvm/msg23341.html however it does not explain a few things that you also do not explain in this reply: 1) Why the kernel module should better be kept that of kernel? I have machines with 2.6.24 kernel, that's years ago, how is it possible that such kernel module is better than what I can compile from kvm-88? (As I explained I am not willing to upgrade the whole kernel on a production machine to avoid introduce new issues, but KVM itself has evolved a lot in the same time, I bet in every aspect, if I can get a stable release) 2) Even in your example below, I don't understand: 2.6.30 was released in june 10, kvm-88 was released in July 12th, why should the kvm kernel module in 2.6.30 be more recent? 3) Everyone here mentions to upgrade the userspace part only. That sounds strange to me because in all kernelmode+usermode applications I have seen up to now, the usermode part was just there to drive the kernelmode part (basically parse commandline parameters and communicate them to the kernel) Ok I understand that in KVM also the emulated devices run in userspace so ok probably also the emulated devices might improve if I upgrade the userspace part, however the most important stuff, that causes a virtual machine to crash or to work correctly, is the kernelmode stuff. Or at least this is what I thought: is this wrong? Also see other questions below -- Michael Tokarev wrote: There's no need to compile kvm _modules_ if you're using recent-enough kernel. Yeah except that this is in contrast with what I have written in my previous post: I don't have a recent kernel (don't know the definition of recent-enough) and I am not really willing to upgrade *all* the kernel. I _fail_ to see why people are still using older and buggy modules from kvm-88 with kernels =2.6.30 where these modules are more recent and with bugfixes. But that's entirely different point. see above question 2 However for compiling from source I would need to know which versions of KVM are stable and which are not. qemu-kvm-n.nn.n are stable releases. First stable release (0.10) already contained the fixes you mentioned. They're versioned exactly like kernel - 0.10.0, 0.10.1, ..., 0.10.6 like 2.6.27 .. 2.6.26.36 or what it is now. Current qemu-kvm is 0.11.0. Great! That is the stable userspace then. But what about stable kernel modules? Are these the kvm-kmod's? And besides, the versioning of kvm-kmod's are not obvious to me: I see these ones at sourceforge: 2.6.31.5 2.6.30 2.6.30.1 2.6.30-rc8 2.6.30-rc6 I don't undestand why they are numbered like the kernel, that's strange... More specifically, this is the question: If I have a kernel version N, what kvm-kmod can I compile in it? If I can just compile version N, then it's useless because that's identical to the kvm.ko I already had. Or can I compile kvm-kmod 2.6.31.5 in my kernel 2.6.24? That's a strange version numbering... why haven't you used the same numbering as for qemu-kvm? kvm-nn never was and never will be for production. They always has been and always will be nothing more than development snapshots. Ok I see. Thanks. Thank you Asdo -- 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: Doubt on KVM-88 vulnerabilities
Asdo wrote: Thanks for your reply, sorry to get you angry, but there are still things which are not clear to me. Well, today wasn't my best day. You're right the documentation on the matter is nearly non-existing. [] 3) Everyone here mentions to upgrade the userspace part only. That sounds strange to me because in all kernelmode+usermode applications I have seen up to now, the usermode part was just there to drive the kernelmode part (basically parse commandline parameters and communicate them to the kernel) Ok I understand that in KVM also the emulated In kvm it's the opposite. Kernel part is very small and the interface does not change as frequently. It's basically just a wrapper around the CPU VT extensions. [] But what about stable kernel modules? Are these the kvm-kmod's? Yes. And besides, the versioning of kvm-kmod's are not obvious to me: I see these ones at sourceforge: 2.6.31.5 2.6.30 2.6.30.1 2.6.30-rc8 2.6.30-rc6 I don't undestand why they are numbered like the kernel, that's strange... More specifically, this is the question: If I have a kernel version N, what kvm-kmod can I compile in it? If I can just compile version N, then it's useless because that's identical to the kvm.ko I already had. Or can I compile kvm-kmod 2.6.31.5 in my kernel 2.6.24? That's a strange version numbering... why haven't you used the same numbering as for qemu-kvm? Because such numbering proved to be confusing, and you are confused by it too. The above numbers means just like, kvm-kmod from kernel 2.6.30.1 (say), but ported to a wider range of kernels. kvm-kmod is being developed as part of kernel. Btw, 2.6.24 and in fact anything before ~2.6.28 might be problematic for real kvm usage, due to other parts of the kernel. Applies to both host and guest kernels. /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: Doubt on KVM-88 vulnerabilities
Great, thanks for your reply! All clear, except one thing, pls see --- Michael Tokarev wrote: 2.6.31.5 2.6.30 2.6.30.1 2.6.30-rc8 2.6.30-rc6 I don't undestand why they are numbered like the kernel, that's strange... More specifically, this is the question: If I have a kernel version N, what kvm-kmod can I compile in it? If I can just compile version N, then it's useless because that's identical to the kvm.ko I already had. Or can I compile kvm-kmod 2.6.31.5 in my kernel 2.6.24? That's a strange version numbering... why haven't you used the same numbering as for qemu-kvm? And besides, the versioning of kvm-kmod's are not obvious to me: I see these ones at sourceforge: Because such numbering proved to be confusing, and you are confused by it too. The above numbers means just like, kvm-kmod from kernel 2.6.30.1 (say), but ported to a wider range of kernels. kvm-kmod is being developed as part of kernel. Ok so you mean I can indeed take kvm-kmod 2.6.31.5 and compile it against my older host kernel? (except that the host kernel needs to be anyway = 2.6.28 as you say below) Did I understand correctly? Btw, 2.6.24 and in fact anything before ~2.6.28 might be problematic for real kvm usage, due to other parts of the kernel. Applies to both host and guest kernels. Thank you Asdo -- 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: [Autotest] [KVM-AUTOTEST PATCH 1/6] KVM test: disable password prompt on resume for Windows guests
Patchset applied, thanks! On Wed, Nov 4, 2009 at 12:05 PM, Michael Goldish mgold...@redhat.com wrote: Add a command to setuprss.bat that disables the password prompt on resuming from hibernation. Note that for this change to take effect the local winutils.iso should be updated as well. Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/deps/setuprss.bat | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/deps/setuprss.bat b/client/tests/kvm/deps/setuprss.bat index 7b6618b..82d620d 100644 --- a/client/tests/kvm/deps/setuprss.bat +++ b/client/tests/kvm/deps/setuprss.bat @@ -5,6 +5,7 @@ copy %rsspath% C:\rss.exe net user Administrator /active:yes net user Administrator 1q2w3eP netsh firewall set opmode disable +powercfg /G OFF /OPTION RESUMEPASSWORD reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v Remote Shell Server /d C:\rss.exe 22 /t REG_SZ /f reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon /v AutoAdminLogon /d 1 /t REG_SZ /f -- 1.5.4.1 ___ Autotest mailing list autot...@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest -- Lucas -- 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: Doubt on KVM-88 vulnerabilities
Asdo wrote: Great, thanks for your reply! All clear, except one thing, pls see --- Michael Tokarev wrote: 2.6.31.5 2.6.30 2.6.30.1 2.6.30-rc8 2.6.30-rc6 I don't undestand why they are numbered like the kernel, that's strange... More specifically, this is the question: If I have a kernel version N, what kvm-kmod can I compile in it? If I can just compile version N, then it's useless because that's identical to the kvm.ko I already had. Or can I compile kvm-kmod 2.6.31.5 in my kernel 2.6.24? That's a strange version numbering... why haven't you used the same numbering as for qemu-kvm? And besides, the versioning of kvm-kmod's are not obvious to me: I see these ones at sourceforge: Because such numbering proved to be confusing, and you are confused by it too. The above numbers means just like, kvm-kmod from kernel 2.6.30.1 (say), but ported to a wider range of kernels. kvm-kmod is being developed as part of kernel. Ok so you mean I can indeed take kvm-kmod 2.6.31.5 and compile it against my older host kernel? (except that the host kernel needs to be anyway = 2.6.28 as you say below) Did I understand correctly? Please see http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/42256 Jan -- Siemens AG, Corporate Technology, CT SE 2 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] Make client behavior configurable: drop_caches
Will this code actually work on a standalone client job? I'm not sure
we've ever used global_config stuff outside of the server (despite the
fact that the code lives in the common_lib).
-- John
On Thu, Nov 5, 2009 at 12:23 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
Right now autotest will drop caches between:
* Test executions
* Same test iterations
This change turns those into configurable options on
global_config.ini. Default configuration:
[CLIENT]
drop_caches: True
drop_caches_between_iterations: True
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/bin/autotest | 7 ++-
client/bin/job.py | 11 ---
global_config.ini | 7 ++-
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/client/bin/autotest b/client/bin/autotest
index fe8f2c7..2d47843 100755
--- a/client/bin/autotest
+++ b/client/bin/autotest
@@ -6,6 +6,7 @@ import os, sys, shutil
import common
from optparse import OptionParser
from autotest_lib.client.bin import job
+from autotest_lib.client.common_lib import global_config
# Use the name of the binary to find the real installation directory
@@ -58,5 +59,9 @@ options, args = parser.parse_args()
if len(args) != 1:
usage()
+drop_caches = global_config.global_config.get_config_value('CLIENT',
+ 'drop_caches',
+ type=bool)
+
# JOB: run the specified job control file.
-job.runjob(os.path.realpath(args[0]), options)
+job.runjob(os.path.realpath(args[0]), drop_caches, options)
diff --git a/client/bin/job.py b/client/bin/job.py
index ebfb3a3..6099188 100755
--- a/client/bin/job.py
+++ b/client/bin/job.py
@@ -15,6 +15,8 @@ from autotest_lib.client.bin import config, sysinfo, test,
local_host
from autotest_lib.client.bin import partition as partition_lib
from autotest_lib.client.common_lib import error, barrier, log,
logging_manager
from autotest_lib.client.common_lib import base_packages, packages
+from autotest_lib.client.common_lib import global_config
+
LAST_BOOT_TAG = object()
NO_DEFAULT = object()
@@ -251,7 +253,10 @@ class base_job(object):
Perform the drop caches initialization.
- self.drop_caches_between_iterations = True
+ self.drop_caches_between_iterations = (
+ global_config.global_config.get_config_value('CLIENT',
+ 'drop_caches_between_iterations',
+ type=bool))
self.drop_caches = drop_caches
if self.drop_caches:
logging.debug(Dropping caches)
@@ -1339,7 +1344,7 @@ class disk_usage_monitor:
return decorator
-def runjob(control, options):
+def runjob(control, drop_caches, options):
Run a job using the given control file.
@@ -1367,7 +1372,7 @@ def runjob(control, options):
if options.cont and not os.path.exists(state):
raise error.JobComplete(all done)
- myjob = job(control, options)
+ myjob = job(control=control, drop_caches=drop_caches,
options=options)
# Load in the users control file, may do any one of:
# 1) execute in toto
diff --git a/global_config.ini b/global_config.ini
index cc20a96..d018374 100644
--- a/global_config.ini
+++ b/global_config.ini
@@ -28,7 +28,6 @@ parse_failed_repair_default: 0
# Autotest potential install paths
client_autodir_paths: /usr/local/autotest,/home/autotest
-
[SERVER]
hostname: autotest
# Turn on RPC Logging
@@ -48,6 +47,12 @@ smtp_port:
smtp_user:
smtp_password:
+[CLIENT]
+# Drop test client caches between every test execution
+drop_caches: True
+# Drop test client caches between every test iteration execution
+drop_caches_between_iterations: True
+
[SCHEDULER]
die_on_orphans: False
enable_scheduler: True
--
1.6.2.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: [Qemu-devel] net packet storms with multiple NICs
I immediately reproduced the problem locally. It turns out that kvm reflects packets coming from one guest NIC on another guest NIC, and since both are connected to the same bridge we're getting endless packet storm. To a level when kvm process becomes 100% busy and does not respond to anything but `kill -9'. You created a network loop. It is working exactly as expected. Create the same topology with a physical network hub and a pair of NICs and you'll get the same end result. Paul -- 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] net packet storms with multiple NICs
Mark McLoughlin wrote: On Fri, 2009-10-23 at 20:25 +0400, Michael Tokarev wrote: I've two questions: o what's the intended usage of all-vlan-equal case, when kvm (or qemu) reflects packets from one interface to another? It's what bridge in linux is for, I think. I don't think it's necessarily an intended use-case for the vlan feature o why different -net guest -net host pairs are not getting different vlan= indexes by default, to stop the above-mentioned packet storms right away? I think it's a wise default to assign different pairs to different vlans, by counting -net host and -net guest sequences. With 0.12, we're going to be de-emphasising the vlan feature and instead have NICs directly connected to host backends. The vlan feature will be just another host backend, but optional You'll start guests with e.g.: -netdev tap,id=tap.0 -device virtio-net-pci,netdev=tap.0 Which is not necessarily more friendly to a user, but it lays the foundation to be able to do a config file which in turns could be easily generated from a nic GUI/command line tool. 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: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation
But I certainly do _not_ want to update the SCSI disk emulation, as this is really quite tied to the SCSI parallel interface used by the old lsi53c895a.c. This is completely untrue. scsi-disk.c contains no transport-specific code. It is deliberately designed to be independent of both the transport (e.g. parallel SCSI or USB) and the mechanism by which the initiator transfers data to the host. Paul -- 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] Make client behavior configurable: drop_caches
On Tue, 2009-11-10 at 10:28 -0800, John Admanski wrote:
Will this code actually work on a standalone client job? I'm not sure
we've ever used global_config stuff outside of the server (despite the
fact that the code lives in the common_lib).
Whoops, I just forgot that global_config.ini is a top level file. 2
possible solutions:
1 - Move global_config.ini to client/
2 - Create a specific configuration file for client.
But yes, the patch has already been applied and introduces a regression
since the stand alone client won't be able to see global_config.ini. I
am sorry.
I believe solution 1) is not bad, client/global_config.ini is just
slightly non intuitive, but splitting conf files does not sound like a
better idea.
-- John
On Thu, Nov 5, 2009 at 12:23 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
Right now autotest will drop caches between:
* Test executions
* Same test iterations
This change turns those into configurable options on
global_config.ini. Default configuration:
[CLIENT]
drop_caches: True
drop_caches_between_iterations: True
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/bin/autotest |7 ++-
client/bin/job.py | 11 ---
global_config.ini |7 ++-
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/client/bin/autotest b/client/bin/autotest
index fe8f2c7..2d47843 100755
--- a/client/bin/autotest
+++ b/client/bin/autotest
@@ -6,6 +6,7 @@ import os, sys, shutil
import common
from optparse import OptionParser
from autotest_lib.client.bin import job
+from autotest_lib.client.common_lib import global_config
# Use the name of the binary to find the real installation directory
@@ -58,5 +59,9 @@ options, args = parser.parse_args()
if len(args) != 1:
usage()
+drop_caches = global_config.global_config.get_config_value('CLIENT',
+ 'drop_caches',
+ type=bool)
+
# JOB: run the specified job control file.
-job.runjob(os.path.realpath(args[0]), options)
+job.runjob(os.path.realpath(args[0]), drop_caches, options)
diff --git a/client/bin/job.py b/client/bin/job.py
index ebfb3a3..6099188 100755
--- a/client/bin/job.py
+++ b/client/bin/job.py
@@ -15,6 +15,8 @@ from autotest_lib.client.bin import config, sysinfo,
test, local_host
from autotest_lib.client.bin import partition as partition_lib
from autotest_lib.client.common_lib import error, barrier, log,
logging_manager
from autotest_lib.client.common_lib import base_packages, packages
+from autotest_lib.client.common_lib import global_config
+
LAST_BOOT_TAG = object()
NO_DEFAULT = object()
@@ -251,7 +253,10 @@ class base_job(object):
Perform the drop caches initialization.
-self.drop_caches_between_iterations = True
+self.drop_caches_between_iterations = (
+
global_config.global_config.get_config_value('CLIENT',
+
'drop_caches_between_iterations',
+type=bool))
self.drop_caches = drop_caches
if self.drop_caches:
logging.debug(Dropping caches)
@@ -1339,7 +1344,7 @@ class disk_usage_monitor:
return decorator
-def runjob(control, options):
+def runjob(control, drop_caches, options):
Run a job using the given control file.
@@ -1367,7 +1372,7 @@ def runjob(control, options):
if options.cont and not os.path.exists(state):
raise error.JobComplete(all done)
-myjob = job(control, options)
+myjob = job(control=control, drop_caches=drop_caches,
options=options)
# Load in the users control file, may do any one of:
# 1) execute in toto
diff --git a/global_config.ini b/global_config.ini
index cc20a96..d018374 100644
--- a/global_config.ini
+++ b/global_config.ini
@@ -28,7 +28,6 @@ parse_failed_repair_default: 0
# Autotest potential install paths
client_autodir_paths: /usr/local/autotest,/home/autotest
-
[SERVER]
hostname: autotest
# Turn on RPC Logging
@@ -48,6 +47,12 @@ smtp_port:
smtp_user:
smtp_password:
+[CLIENT]
+# Drop test client caches between every test execution
+drop_caches: True
+# Drop test client caches between every test iteration execution
+drop_caches_between_iterations: True
+
[SCHEDULER]
die_on_orphans: False
enable_scheduler: True
--
1.6.2.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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: kvm book3s issues
On 10.11.2009, at 08:20, Benjamin Herrenschmidt wrote:
Hi Alex !
After a bit of digging as to why the karmic installer dies, I found
out
that you don't set the right SRR1 bits when forwarding a program check
exception to the guest.
Cool, thanks for trying things out and debugging them! :-)
I also did a couple of minor fixups (though the s/mtmsr/mtmsrd may not
be necessary, I think the clearing of HID5 is). Patch below, haven't
had
a chance to clean it up into a proper submission yet.
I didn't go very much further yet with the karmic graphical installer,
but that isn't a surprise. I'll try the text one as soon as I get to
d/l
the alternate ISO.
Cheers,
Ben.
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..a094ca9 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -627,6 +627,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
struct kvm_vcpu *vcpu,
#endif
if ((vcpu-arch.last_inst 0xff0007ff) !=
(INS_DCBZ 0xfff7)) {
+ vcpu-arch.msr |= (vcpu-arch.shadow_msr
0x1full);
What bits are those? It might be good to use real #define's here :-).
kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
r = RESUME_GUEST;
break;
@@ -642,6 +643,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
struct kvm_vcpu *vcpu,
case EMULATE_FAIL:
printk(KERN_CRIT %s: emulation at %lx failed (%08x)\n,
__func__, vcpu-arch.pc, vcpu-arch.last_inst);
+ vcpu-arch.msr |= (vcpu-arch.shadow_msr 0x1full);
kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
r = RESUME_GUEST;
break;
diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/
kvm/book3s_64_interrupts.S
index 7b55d80..22f2962 100644
--- a/arch/powerpc/kvm/book3s_64_interrupts.S
+++ b/arch/powerpc/kvm/book3s_64_interrupts.S
@@ -241,8 +241,9 @@ kvmppc_handler_highmem:
rldicl. r5, r5, 0, 63 /* CR = ((r5 1) == 0) */
beq no_dcbz32_off
+ li r4,0
mfspr r5,SPRN_HID5
- rldimi r5,r5,6,56
+ rldimi r5,r4,6,56
When you're on a G5 you never get into this code path, right? You're
using the dcbz binary patched emulation instead.
So what you do is you replace
HID5 = ~DCBZ32;
with
HID5 = 0;
Is that intentional?
mtspr SPRN_HID5,r5
no_dcbz32_off:
diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/
book3s_64_slb.S
index ecd237a..c574cf7 100644
--- a/arch/powerpc/kvm/book3s_64_slb.S
+++ b/arch/powerpc/kvm/book3s_64_slb.S
@@ -205,11 +205,11 @@ ld_last_inst:
/*1) enable paging for data */
mfmsr r9
ori r11, r9, MSR_DR /* Enable paging for data */
- mtmsr r11
+ mtmsrd r11
Wasn't mtmsrd this extra cool new version that takes a second argument
so one can only set IF?
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: kvm book3s issues
On Tue, 2009-11-10 at 11:50 +0100, Alexander Graf wrote:
if ((vcpu-arch.last_inst 0xff0007ff) !=
(INS_DCBZ 0xfff7)) {
+ vcpu-arch.msr |= (vcpu-arch.shadow_msr
0x1full);
What bits are those? It might be good to use real #define's here :-).
They are some of those SRR1 bits that don't match MSR bits, used to
convey informations on program check and machine check. I think the only
#define we have for them are actually deep inside traps.c.
diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/
kvm/book3s_64_interrupts.S
index 7b55d80..22f2962 100644
--- a/arch/powerpc/kvm/book3s_64_interrupts.S
+++ b/arch/powerpc/kvm/book3s_64_interrupts.S
@@ -241,8 +241,9 @@ kvmppc_handler_highmem:
rldicl. r5, r5, 0, 63 /* CR = ((r5 1) == 0) */
beq no_dcbz32_off
+ li r4,0
mfspr r5,SPRN_HID5
- rldimi r5,r5,6,56
+ rldimi r5,r4,6,56
When you're on a G5 you never get into this code path, right? You're
using the dcbz binary patched emulation instead.
Why ? The G5 is a 970 which supports HID5 and has no hypervisor to get
in the way so it works fine with the dcbz hack (I added printks to
verify it was enabled).
So what you do is you replace
HID5 = ~DCBZ32;
with
HID5 = 0;
No. What I do is replace
HID5 = (HID5 ~0xc0) | ((HID5 0x3) 6)
with
HID5 = (HID5 ~0xc0)
At least that's my understanding :-)
Is that intentional?
mtspr SPRN_HID5,r5
no_dcbz32_off:
diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/
book3s_64_slb.S
index ecd237a..c574cf7 100644
--- a/arch/powerpc/kvm/book3s_64_slb.S
+++ b/arch/powerpc/kvm/book3s_64_slb.S
@@ -205,11 +205,11 @@ ld_last_inst:
/*1) enable paging for data */
mfmsr r9
ori r11, r9, MSR_DR /* Enable paging for data */
- mtmsr r11
+ mtmsrd r11
Wasn't mtmsrd this extra cool new version that takes a second argument
so one can only set IF?
Extra argument is optional in the asm but yeah. Though I think mtmsr
also takes it (the L bit basically). No, the difference is that mtmsrd
can write all 64-bit of the MSR while mtmsr only the low 32-bit. Now in
your case that's fine, both would work, I just did that change as a
reflex :-) (Ie. mtmsr will preserve the top 32-bit of the MSR anyway)
Note: The karmic installer still goes bonkers a bit later, I don't know
why yet (works without -enable-kvm). I need to run it without it's
quiet thingy so I can see what's happening :-)
Cheers,
Ben.
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: kvm book3s issues
On 10.11.2009, at 22:16, Benjamin Herrenschmidt wrote:
On Tue, 2009-11-10 at 11:50 +0100, Alexander Graf wrote:
if ((vcpu-arch.last_inst 0xff0007ff) !=
(INS_DCBZ 0xfff7)) {
+ vcpu-arch.msr |= (vcpu-arch.shadow_msr
0x1full);
What bits are those? It might be good to use real #define's here :-).
They are some of those SRR1 bits that don't match MSR bits, used to
convey informations on program check and machine check. I think the
only
#define we have for them are actually deep inside traps.c.
I see ;-).
diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/
kvm/book3s_64_interrupts.S
index 7b55d80..22f2962 100644
--- a/arch/powerpc/kvm/book3s_64_interrupts.S
+++ b/arch/powerpc/kvm/book3s_64_interrupts.S
@@ -241,8 +241,9 @@ kvmppc_handler_highmem:
rldicl. r5, r5, 0, 63 /* CR = ((r5 1) == 0) */
beq no_dcbz32_off
+ li r4,0
mfspr r5,SPRN_HID5
- rldimi r5,r5,6,56
+ rldimi r5,r4,6,56
When you're on a G5 you never get into this code path, right? You're
using the dcbz binary patched emulation instead.
Why ? The G5 is a 970 which supports HID5 and has no hypervisor to get
in the way so it works fine with the dcbz hack (I added printks to
verify it was enabled).
Oh right. Mac OS X enables it too - I forgot.
So what you do is you replace
HID5 = ~DCBZ32;
with
HID5 = 0;
No. What I do is replace
HID5 = (HID5 ~0xc0) | ((HID5 0x3) 6)
with
HID5 = (HID5 ~0xc0)
At least that's my understanding :-)
+ li r4,0
mfspr r5,SPRN_HID5
r5 = *HID5
- rldimi r5,r5,6,56
Take r5, remove some bits, write into r5
+ rldimi r5,r4,6,56
Take r4, remove some bits, write into r5.
Or did I miss anything?
Is that intentional?
mtspr SPRN_HID5,r5
no_dcbz32_off:
diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/
book3s_64_slb.S
index ecd237a..c574cf7 100644
--- a/arch/powerpc/kvm/book3s_64_slb.S
+++ b/arch/powerpc/kvm/book3s_64_slb.S
@@ -205,11 +205,11 @@ ld_last_inst:
/*1) enable paging for data */
mfmsr r9
ori r11, r9, MSR_DR /* Enable paging for data */
- mtmsr r11
+ mtmsrd r11
Wasn't mtmsrd this extra cool new version that takes a second
argument
so one can only set IF?
Extra argument is optional in the asm but yeah. Though I think mtmsr
also takes it (the L bit basically). No, the difference is that mtmsrd
can write all 64-bit of the MSR while mtmsr only the low 32-bit. Now
in
your case that's fine, both would work, I just did that change as a
reflex :-) (Ie. mtmsr will preserve the top 32-bit of the MSR anyway)
Ah, right. Thanks for the catch!
Note: The karmic installer still goes bonkers a bit later, I don't
know
why yet (works without -enable-kvm). I need to run it without it's
quiet thingy so I can see what's happening :-)
Hum, would be interesting to know where it breaks. Either way you're
running the guest pretty far already as userspace is apparently
running. So that's good news :-).
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: kvm book3s issues
On 11.11.2009, at 02:03, Benjamin Herrenschmidt wrote: + li r4,0 mfspr r5,SPRN_HID5 r5 = *HID5 So far so good... - rldimi r5,r5,6,56 Take r5, remove some bits, write into r5 Hrm... nope :-) rldimi will insert into the destination (r5) bits 56..57 the corresponding bits from the source (r5) after that source has been rotated left by 6 bits. That means inserting the 2 low bits of r5 into r5[56:57] afaik :-) + rldimi r5,r4,6,56 Take r4, remove some bits, write into r5. My variant will insert the bits from r4 which is 0, means it's going to insert 0's in r5[56:57] which is what you want (clear the two dcbz special bits) right ? Or did I miss anything? I think you did :-) Wow, and there I thought I finally mastered the rotate instructions :-). 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: kvm book3s issues
On Wed, 2009-11-11 at 02:06 +0100, Alexander Graf wrote: On 11.11.2009, at 02:03, Benjamin Herrenschmidt wrote: +li r4,0 mfspr r5,SPRN_HID5 r5 = *HID5 So far so good... -rldimi r5,r5,6,56 Take r5, remove some bits, write into r5 Hrm... nope :-) rldimi will insert into the destination (r5) bits 56..57 the corresponding bits from the source (r5) after that source has been rotated left by 6 bits. That means inserting the 2 low bits of r5 into r5[56:57] afaik :-) +rldimi r5,r4,6,56 Take r4, remove some bits, write into r5. My variant will insert the bits from r4 which is 0, means it's going to insert 0's in r5[56:57] which is what you want (clear the two dcbz special bits) right ? Or did I miss anything? I think you did :-) Wow, and there I thought I finally mastered the rotate instructions :-). Well, that's a rotate-and-insert in fact :-) But please dbl check the doco to make sure I didn't get it wrong. Also sadly, you cannot use rlwinm in this case to clear bits because that would put crap into the top half of the register Cheers, Ben. -- 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
