[PATCH] KVM: x86: Reset pending/inject NMI state on CPU reset
From: Jan Kiszka [EMAIL PROTECTED]
CPU reset invalidates pending or already injected NMIs, therefore reset
the related state variables.
Based on original patch by Gleb Natapov.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4cfdd1b..3c64951 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4179,6 +4179,9 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
{
+ vcpu-arch.nmi_pending = false;
+ vcpu-arch.nmi_injected = false;
+
return kvm_x86_ops-vcpu_reset(vcpu);
}
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] kvm-userspace: kvmppc: fix build for ppc v2
From: Christian Ehrhardt [EMAIL PROTECTED] *update Short after resending v1 I realized that I forgot to put Avi and [EMAIL PROTECTED] (for 2/3) on cc. I also updated the header text in 1/3 a bit and verified my hostlongbits proposal on recent cross toolchain versions because there was a question about that. Updating and testing kvm-userspace for ppc after a too long time brought up some issues fixed in this series. The patches are small and their description should be comprehendible. Due to the fact that most of the issues where build time issues I also started to discuss about/establish some kind of automated build test for us that should allow us to find such things faster. Let me know if qumranet has such a process for x86 already and I should help you to include powerpc. [patches in series] [PATCH 1/3] kvm-userspace: kvmppc: fix file header in libkvm-powerpc.c [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling [PATCH 3/3] kvm-userspace: kvmppc: fix building userspace for powerpc --- [diffstat] Makefile |3 ++- kernel/powerpc/Makefile.pre|1 + kernel/powerpc/hack-module.awk |5 + libkvm/libkvm-powerpc.c| 14 +- qemu/Makefile.target |2 +- qemu/configure | 13 +++-- 6 files changed, 21 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling
From: Christian Ehrhardt [EMAIL PROTECTED]
A recent kvm merge with qemu brought code for 64bit power that broke cross
compilation. The issue is caused by configure trying to execute target
architecture binaries where configure is executed.
I tried to change that detection so that it works withwithout cross
compilation with only a small change and especially without an addtional
configure command line switch. Including the bits/wordsize.h header a platform
usually can check its wordsize and by doing that configure can check the
hostlongbits without executing the binary. Instead it now stops after
preprocessing stage which resolved the __WORDSIZE constant and retrieves
that value.
I don't like my new check style, but it is at least less broken than before.
Another approach that was suggested was that qemu might end up needing
something like asm-offsets in the kernel to manage architecture sizes etc.
Comments and other approaches welcome.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
configure | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
[diff]
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -685,14 +685,15 @@
# ppc specific hostlongbits selection
if test $cpu = powerpc ; then
cat $TMPC EOF
-int main(void){return sizeof(long);}
+#include bits/wordsize.h
+__WORDSIZE
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null; then
-$TMPE
-case $? in
-4) hostlongbits=32;;
-8) hostlongbits=64;;
+if $cc $ARCH_CFLAGS -E -o $TMPE.E $TMPC 2 /dev/null; then
+wordsize=`tail -n 1 ${TMPE}.E`
+case $wordsize in
+32) hostlongbits=32;;
+64) hostlongbits=64;;
*) echo Couldn't determine bits per long value; exit 1;;
esac
else
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] kvm-userspace: kvmppc: fix building userspace for powerpc
From: Christian Ehrhardt [EMAIL PROTECTED]
Last submission missed the right 3/3 tag so I resend it to be recognized.
Commit 2d5737d8 added the requirement for an $arch/Makefile.pre in the
kernel subdirectory. This patch adds a stub for powerpc.
Additionally now a file kernel/$arch/hack-module.awk is needed and a simple
version for ppc is added for that one too.
In the root Makefile ia64 patch 030253bf added ia64 with a comma which should
break both architectures because filter works without. The patch removes that
comma.
The commit 76ff90aa fixed the dependency to DEPLIBS, but the definition of the
libfdt dependency lacks the right path (../libfdt/).
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
Makefile |2 +-
kernel/powerpc/Makefile.pre|1 +
kernel/powerpc/hack-module.awk |5 +
qemu/Makefile.target |2 +-
4 files changed, 8 insertions(+), 2 deletions(-)
[diff]
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -23,7 +23,7 @@
ifneq '$(filter $(ARCH), i386 x86_64)' ''
qemu: extboot
endif
-ifneq '$(filter $(ARCH), powerpc, ia64)' ''
+ifneq '$(filter $(ARCH), powerpc ia64)' ''
qemu: libfdt
endif
user: libkvm
diff --git a/kernel/powerpc/Makefile.pre b/kernel/powerpc/Makefile.pre
new file mode 100644
--- /dev/null
+++ b/kernel/powerpc/Makefile.pre
@@ -0,0 +1,1 @@
+prerequisite:
diff --git a/kernel/powerpc/hack-module.awk b/kernel/powerpc/hack-module.awk
new file mode 100644
--- /dev/null
+++ b/kernel/powerpc/hack-module.awk
@@ -0,0 +1,5 @@
+/MODULE_AUTHOR/ {
+printf(MODULE_INFO(version, \%s\);\n, version)
+}
+
+{ print }
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -579,7 +579,7 @@
ifdef CONFIG_LIBFDT
LIBS += -lfdt
-DEPLIBS += libfdt.a
+DEPLIBS += ../libfdt/libfdt.a
endif
# SCSI layer
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] kvm-userspace: kvmppc: fix file header in libkvm-powerpc.c v2
From: Christian Ehrhardt [EMAIL PROTECTED] It came up in the review of the s390 libkvm code that we have some broken headers too. Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED] --- [diffstat] libkvm-powerpc.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) [diff] diff --git a/libkvm/libkvm-powerpc.c b/libkvm/libkvm-powerpc.c --- a/libkvm/libkvm-powerpc.c +++ b/libkvm/libkvm-powerpc.c @@ -1,10 +1,7 @@ /* - * This header is for functions variables that will ONLY be - * used inside libkvm for x86. - * THESE ARE NOT EXPOSED TO THE USER AND ARE ONLY FOR USE - * WITHIN LIBKVM. - * - * derived from libkvm.c + * This file contains the powerpc specific implementation for the + * architecture dependent functions defined in kvm-common.h and + * libkvm.h * * Copyright (C) 2006 Qumranet, Inc. * @@ -12,11 +9,10 @@ * Avi Kivity [EMAIL PROTECTED] * Yaniv Kamay [EMAIL PROTECTED] * - * Copyright 2007 IBM Corporation. - * Added by Authors: + * Copyright IBM Corp. 2007,2008 + * Authors: * Jerone Young [EMAIL PROTECTED] * Christian Ehrhardt [EMAIL PROTECTED] - * * * This work is licensed under the GNU LGPL license, version 2. */ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: x86: Silence various LAPIC-related host kernel messages
KVM-x86 dumps a lot of debug messages that have no meaning for normal
operation:
- INIT de-assertion is ignored
- SIPIs are sent and received
- APIC writes are unaligned or 4 byte long
(Windows Server 2003 triggers this on SMP)
Degrade them to true debug messages, keeping the host kernel log clean
for real problems.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/lapic.c | 16 +++-
arch/x86/kvm/x86.c |4 ++--
2 files changed, 9 insertions(+), 11 deletions(-)
Index: b/arch/x86/kvm/lapic.c
===
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -365,16 +365,14 @@ static int __apic_accept_irq(struct kvm_
vcpu-arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
kvm_vcpu_kick(vcpu);
} else {
- printk(KERN_DEBUG
- Ignoring de-assert INIT to vcpu %d\n,
- vcpu-vcpu_id);
+ apic_debug(Ignoring de-assert INIT to vcpu %d\n,
+ vcpu-vcpu_id);
}
-
break;
case APIC_DM_STARTUP:
- printk(KERN_DEBUG SIPI to vcpu %d vector 0x%02x\n,
- vcpu-vcpu_id, vector);
+ apic_debug(SIPI to vcpu %d vector 0x%02x\n,
+ vcpu-vcpu_id, vector);
if (vcpu-arch.mp_state == KVM_MP_STATE_INIT_RECEIVED) {
vcpu-arch.sipi_vector = vector;
vcpu-arch.mp_state = KVM_MP_STATE_SIPI_RECEIVED;
@@ -679,9 +677,9 @@ static void apic_mmio_write(struct kvm_i
* Refer SDM 8.4.1
*/
if (len != 4 || alignment) {
- if (printk_ratelimit())
- printk(KERN_ERR apic write: bad size=%d %lx\n,
- len, (long)address);
+ /* Don't shout loud, $infamous_os would cause only noise. */
+ apic_debug(apic write: bad size=%d %lx\n,
+ len, (long)address);
return;
}
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3224,8 +3224,8 @@ static int __vcpu_run(struct kvm_vcpu *v
int r;
if (unlikely(vcpu-arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
- printk(vcpu %d received sipi with vector # %x\n,
- vcpu-vcpu_id, vcpu-arch.sipi_vector);
+ pr_debug(vcpu %d received sipi with vector # %x\n,
+vcpu-vcpu_id, vcpu-arch.sipi_vector);
kvm_lapic_reset(vcpu);
r = kvm_x86_ops-vcpu_reset(vcpu);
if (r)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
From: Christian Ehrhardt [EMAIL PROTECTED]
*update*
further debugging according to some requests revealed that ARCH_CFLAGS does
not contain all CFLAGS that might be needed, especially those supplied via
extra-cflags. Therefore people supplying things via extra-cflags instead of an
environment variable might have had issues.
A recent kvm merge with qemu brought code for 64bit power that broke cross
compilation. The issue is caused by configure trying to execute target
architecture binaries where configure is executed.
I tried to change that detection so that it works withwithout cross
compilation with only a small change and especially without an addtional
configure command line switch. Including the bits/wordsize.h header a platform
usually can check its wordsize and by doing that configure can check the
hostlongbits without executing the binary. Instead it now stops after
preprocessing stage which resolved the __WORDSIZE constant and retrieves
that value.
I don't like my new check style, but it is at least less broken than before.
Another approach that was suggested was that qemu might end up needing
something like asm-offsets in the kernel to manage architecture sizes etc.
Comments and other approaches welcome.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
configure | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
[diff]
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -685,14 +685,15 @@
# ppc specific hostlongbits selection
if test $cpu = powerpc ; then
cat $TMPC EOF
-int main(void){return sizeof(long);}
+#include bits/wordsize.h
+__WORDSIZE
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null; then
-$TMPE
-case $? in
-4) hostlongbits=32;;
-8) hostlongbits=64;;
+if $cc $ARCH_CFLAGS $CFLAGS -E -o $TMPE.E $TMPC 2 /dev/null; then
+wordsize=`tail -n 1 ${TMPE}.E`
+case $wordsize in
+32) hostlongbits=32;;
+64) hostlongbits=64;;
*) echo Couldn't determine bits per long value; exit 1;;
esac
else
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2137862 ] Kernels with CONFIG_KVM_GUEST are broken on kvm-76
Bugs item #2137862, was opened at 2008-09-30 12:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2137862group_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: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Zhidovinov (mzhidovinov) Assigned to: Nobody/Anonymous (nobody) Summary: Kernels with CONFIG_KVM_GUEST are broken on kvm-76 Initial Comment: Kernels compiled with CONFIG_KVM_GUEST (e.g. 2.6.26/27 kernels from Fedora10/rawhide or Ubuntu 8.10) breaks in mysterious ways in early userspace. Host is x86_64 Intel's Core2 (Xeon 5138) with kernel from kvm git. Guests are both x86_64 and i386. Kernels with CONFIG_KVM_GUEST not set are fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2137862group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2137862 ] Linux kKernels with CONFIG_KVM_GUEST are broken on kvm-76
Bugs item #2137862, was opened at 2008-09-30 12:36 Message generated for change (Settings changed) made by mzhidovinov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2137862group_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: kernel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Zhidovinov (mzhidovinov) Assigned to: Nobody/Anonymous (nobody) Summary: Linux kKernels with CONFIG_KVM_GUEST are broken on kvm-76 Initial Comment: Kernels compiled with CONFIG_KVM_GUEST (e.g. 2.6.26/27 kernels from Fedora10/rawhide or Ubuntu 8.10) breaks in mysterious ways in early userspace. Host is x86_64 Intel's Core2 (Xeon 5138) with kernel from kvm git. Guests are both x86_64 and i386. Kernels with CONFIG_KVM_GUEST not set are fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2137862group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2137862 ] Linux kernels with CONFIG_KVM_GUEST are broken on kvm-76
Bugs item #2137862, was opened at 2008-09-30 12:36 Message generated for change (Settings changed) made by mzhidovinov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2137862group_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: kernel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Zhidovinov (mzhidovinov) Assigned to: Nobody/Anonymous (nobody) Summary: Linux kernels with CONFIG_KVM_GUEST are broken on kvm-76 Initial Comment: Kernels compiled with CONFIG_KVM_GUEST (e.g. 2.6.26/27 kernels from Fedora10/rawhide or Ubuntu 8.10) breaks in mysterious ways in early userspace. Host is x86_64 Intel's Core2 (Xeon 5138) with kernel from kvm git. Guests are both x86_64 and i386. Kernels with CONFIG_KVM_GUEST not set are fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2137862group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows 2003, virtio Ethernet and USB - Strange Interaction
Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Sven -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Le mardi 30 septembre 2008 à 10:41 +0200, Sven Rudolph a écrit : Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin Where is coming from your rom ? Is etherboot or gPXE rom ? This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Is linux able to reboot ? Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Did you try to reduce the amount of memory (-m 1024) ? Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Laurent Vivier [EMAIL PROTECTED] writes: Le mardi 30 septembre 2008 à 10:41 +0200, Sven Rudolph a écrit : Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin Where is coming from your rom ? http://www.mail-archive.com/kvm@vger.kernel.org/msg00631.html Is etherboot or gPXE rom ? It says Etherboot 5.4.3. I just tried a gPXE Image from http://rom-o-matic.net (Version 0.9.4 and git (gpxe-0.9.4-virtio-net.rom and gpxe-git-virtio-net.rom)), and it behaves the same. This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Is linux able to reboot ? When Linux runs, the virtio Ethernet works fine. It can be rebooted, and when I do it, the freshly booted Linux and its virtio Ethernet still work fine. Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Did you try to reduce the amount of memory (-m 1024) ? I just tested it, the problem still appears. Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Thanks, Sven -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138079 ] kvm locks up system
Bugs item #2138079, was opened at 2008-09-30 14:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138079group_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: Torok Edwin (edwin128) Assigned to: Nobody/Anonymous (nobody) Summary: kvm locks up system Initial Comment: Sometimes KVM locks up the entire system for several minutes. When this happens I can't use neither the keyboard nor the mouse. I can login remotely using ssh and kill kvm, and then keyboard is restored after a short while, however I need to restart X, because the mouse remains grabbed. Last time it happened while using a NetBSD 4.0 (x86_64) image. I've done a commit all on the qemu console, then switched back to the guest, and I couldn't type anything, after that I couldn't exit the grab either, and after that the system locked up. I had gkrellm running, and it showed 1 core having 100% system time, while the other 3 cores were idle. Before this happened were at 99% user CPU usage, from another process (not kvm/qemu). System info: * distro: Debian unstable * CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz * KVM version: 76 * host kernel: 2.6.26-1-amd64 #1 SMP Wed Sep 24 13:59:41 UTC 2008 x86_64 GNU/Linux * host arch: x86_64 * guest: x86_64, NetBSD 4.0 (on serial console, boot fails if using text console) * qemu cmdline: sudo qemu-system-x86_64 -hda netbsd4.img -snapshot -m 1024 -cdrom /tmp/x.iso * the problem only appears with kvm, I never encountered this when using -no-kvm, or when using qemu w/ kqemu. * this problem also occured when running a Solaris 10 guest OS dmesg output during lockup below. See also kerneloops entry: http://kerneloops.org/guilty.php?guilty=apic_mmio_readversion=2.6.26-releasestart=1736704end=1769471class=oops [12518.803078] loaded kvm module (kvm-76) [12564.289154] kvm: emulating exchange as write [13926.593155] kvm: inject_page_fault: double fault 0x80c0bfa8 [14015.554904] BUG: soft lockup - CPU#1 stuck for 61s! [qemu-system-x86:20613] [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] CPU 1: [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] Pid: 20613, comm: qemu-system-x86 Tainted: P 2.6.26-1-amd64 #1 [14015.554904] RIP: 0010:[a0c0fa32] [a0c0fa32] :kvm:apic_mmio_read+0xf0/0x17d [14015.554904] RSP: 0018:81000821dc88 EFLAGS: 0202 [14015.554904] RAX: 62126c0cf17912e9 RBX: 0390 RCX: 62126c0cf2841a1b [14015.554904] RDX: 010b0732 RSI: 010b0732 RDI: fef4f8ce [14015.554904] RBP: fee0017b R08: 0001 R09: 0c12 [14015.554904] R10: R11: a0c60c5b R12: 000380281e01 [14015.554904] R13: 00c18dc0 R14: 0003 R15: 809b8390 [14015.554904] FS: 420ce950() GS:81012fa7c8c0() knlGS: [14015.554904] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [14015.554904] CR2: CR3: 91b53000 CR4:
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops register interface
On Tue, Sep 30, 2008 at 01:10:28PM +0200, Ingo Molnar wrote:
* Joerg Roedel [EMAIL PROTECTED] wrote:
+static int calgary_device_supported(struct device *dev)
+{
+ struct iommu_table *tbl;
+
+ tbl = find_iommu_table(dev);
+
+ return translation_enabled(tbl);
+}
i guess this could be written as a simple:
+static int calgary_device_supported(struct device *dev)
+{
+ return translation_enabled(find_iommu_table(dev));
+}
?
Yes. I will change it.
Joerg
--
| AMD Saxony Limited Liability Company Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System| Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center| AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138149 ] Allow acpi events be send to kvm guests from userspace
Bugs item #2138149, was opened at 2008-09-30 14:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138149group_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: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Poelzleithner (poelzi) Assigned to: Nobody/Anonymous (nobody) Summary: Allow acpi events be send to kvm guests from userspace Initial Comment: It would be wonderfull if the userspace of the host system would have scripts to trigger acpi events in vms. This would allow a full virtualized notebook to handle correctly acpi events triggered by special keys of notebooks, open/close of the lid, etc. I let the X server run on the host and connect through network X to the guest vm. But things like activating the screensave in the vm is not easy possible. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138149group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138166 ] Vista guest fails to start on kvm-76
Bugs item #2138166, was opened at 2008-09-30 08:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138166group_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: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Vista guest fails to start on kvm-76 Initial Comment: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Build: kvm-76 Host kernel: 2.6.26.3-29.fc9.x86_64 Host arch: x86_64 Guest: Windows Vista Ultimate 64-bit QEMU command: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -std-vga -full-screen -smp 2 I've been running this guest on this host with kvm-75 without difficulty. kvm-76, built the same way that kvm-75 was (and on the same machine), fails to start my guest. The guest window is up, but the guest fails to complete startup. Command line output is: kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists set_vram_mapping failed kvm: get_dirty_pages returned -2 The last line repeats hundreds of times. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138166group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops register interface
On Tue, Sep 30, 2008 at 01:10:28PM +0200, Ingo Molnar wrote:
* Joerg Roedel [EMAIL PROTECTED] wrote:
+static int calgary_device_supported(struct device *dev)
+{
+ struct iommu_table *tbl;
+
+ tbl = find_iommu_table(dev);
+
+ return translation_enabled(tbl);
+}
i guess this could be written as a simple:
+static int calgary_device_supported(struct device *dev)
+{
+ return translation_enabled(find_iommu_table(dev));
+}
Sure, but I prefer the explicit form since it lends itself to easier
debugging (oops line numbers, adding printks, etc.).
Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
xxx
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 0/5] bios: 4G updates
Avi Kivity wrote: I tried to merge it, but it the new bios won't boot. I traced this to ata_reset: it toggles the soft reset bit in the command register and expects to see the busy bit set, but the ide device model returns zero status if the selected device has no drive. No idea if the device model or the bios is wrong. If anyone (hi Gleb) wants to take a look, it's in the branch bios-merge on git.kernel.org. btw, commenting this out leads to boot failure as well, but that may be related. Okay, I think I have it -- the bios code was using .org to set certain entry points to well known addresses, and one code section overflowed due to enabling the cache, which is a kvm addition. Moving that bit out-of-line allows the bios to boot. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138166 ] Vista guest fails to start on kvm-76
Bugs item #2138166, was opened at 2008-09-30 07:39 Message generated for change (Comment added) made by iggy_cav You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138166group_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: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Vista guest fails to start on kvm-76 Initial Comment: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Build: kvm-76 Host kernel: 2.6.26.3-29.fc9.x86_64 Host arch: x86_64 Guest: Windows Vista Ultimate 64-bit QEMU command: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -std-vga -full-screen -smp 2 I've been running this guest on this host with kvm-75 without difficulty. kvm-76, built the same way that kvm-75 was (and on the same machine), fails to start my guest. The guest window is up, but the guest fails to complete startup. Command line output is: kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists set_vram_mapping failed kvm: get_dirty_pages returned -2 The last line repeats hundreds of times. -- Comment By: Brian Jackson (iggy_cav) Date: 2008-09-30 09:06 Message: This was reported on the mailing list. It's a problem with sdl output. Not specific to any guest. Until the problem is fixed, I'd suggest using vnc output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138166group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138149 ] Allow acpi events be send to kvm guests from userspace
Bugs item #2138149, was opened at 2008-09-30 07:30 Message generated for change (Comment added) made by iggy_cav You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138149group_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: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Poelzleithner (poelzi) Assigned to: Nobody/Anonymous (nobody) Summary: Allow acpi events be send to kvm guests from userspace Initial Comment: It would be wonderfull if the userspace of the host system would have scripts to trigger acpi events in vms. This would allow a full virtualized notebook to handle correctly acpi events triggered by special keys of notebooks, open/close of the lid, etc. I let the X server run on the host and connect through network X to the guest vm. But things like activating the screensave in the vm is not easy possible. -- Comment By: Brian Jackson (iggy_cav) Date: 2008-09-30 09:08 Message: This sounds like something to be taken up with management tool providers and upstream qemu. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138149group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 2008-09-30 at 11:10 +0200, [EMAIL PROTECTED] wrote:
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -685,14 +685,15 @@
# ppc specific hostlongbits selection
if test $cpu = powerpc ; then
cat $TMPC EOF
-int main(void){return sizeof(long);}
+#include bits/wordsize.h
+__WORDSIZE
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null; then
-$TMPE
-case $? in
-4) hostlongbits=32;;
-8) hostlongbits=64;;
+if $cc $ARCH_CFLAGS $CFLAGS -E -o $TMPE.E $TMPC 2 /dev/null; then
+wordsize=`tail -n 1 ${TMPE}.E`
+case $wordsize in
+32) hostlongbits=32;;
+64) hostlongbits=64;;
*) echo Couldn't determine bits per long value; exit 1;;
esac
else
Yeah, trying to execute target-specific code is simply incompatible with
cross-compiling, so clearly this needs to be changed.
bits/wordsize.h might be too Linux-specific, not sure. Also, I worry
about the preprocessor being allowed to insert all the whitespace it
wants, so I'm not sure if you can assume that __WORDSIZE will be on the
last output line.
Instead you could use this:
$cc -E -dM - /dev/null | grep __powerpc64__
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] kvm-userspace: kvmppc: fix build for ppc v2
On Tue, 2008-09-30 at 08:36 +0200, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update Short after resending v1 I realized that I forgot to put Avi and [EMAIL PROTECTED] (for 2/3) on cc. I also updated the header text in 1/3 a bit and verified my hostlongbits proposal on recent cross toolchain versions because there was a question about that. Updating and testing kvm-userspace for ppc after a too long time brought up some issues fixed in this series. The patches are small and their description should be comprehendible. Due to the fact that most of the issues where build time issues I also started to discuss about/establish some kind of automated build test for us that should allow us to find such things faster. Let me know if qumranet has such a process for x86 already and I should help you to include powerpc. [patches in series] [PATCH 1/3] kvm-userspace: kvmppc: fix file header in libkvm-powerpc.c [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling [PATCH 3/3] kvm-userspace: kvmppc: fix building userspace for powerpc Acked-by: Hollis Blanchard [EMAIL PROTECTED] Avi, assuming agreement from qemu folks on patch #2, please apply these. Thanks. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops register interface
* Muli Ben-Yehuda [EMAIL PROTECTED] wrote:
+static int calgary_device_supported(struct device *dev)
+{
+ return translation_enabled(find_iommu_table(dev));
+}
Sure, but I prefer the explicit form since it lends itself to easier
debugging (oops line numbers, adding printks, etc.).
we never do that for simple stuff like this. The kernel would be twice
as large if we did. An oops is easy enough to decode and an oops does
not come with a line number.
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138079 ] kvm locks up system
Bugs item #2138079, was opened at 2008-09-30 14:36 Message generated for change (Comment added) made by edwin128 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2138079group_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: Torok Edwin (edwin128) Assigned to: Nobody/Anonymous (nobody) Summary: kvm locks up system Initial Comment: Sometimes KVM locks up the entire system for several minutes. When this happens I can't use neither the keyboard nor the mouse. I can login remotely using ssh and kill kvm, and then keyboard is restored after a short while, however I need to restart X, because the mouse remains grabbed. Last time it happened while using a NetBSD 4.0 (x86_64) image. I've done a commit all on the qemu console, then switched back to the guest, and I couldn't type anything, after that I couldn't exit the grab either, and after that the system locked up. I had gkrellm running, and it showed 1 core having 100% system time, while the other 3 cores were idle. Before this happened were at 99% user CPU usage, from another process (not kvm/qemu). System info: * distro: Debian unstable * CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz * KVM version: 76 * host kernel: 2.6.26-1-amd64 #1 SMP Wed Sep 24 13:59:41 UTC 2008 x86_64 GNU/Linux * host arch: x86_64 * guest: x86_64, NetBSD 4.0 (on serial console, boot fails if using text console) * qemu cmdline: sudo qemu-system-x86_64 -hda netbsd4.img -snapshot -m 1024 -cdrom /tmp/x.iso * the problem only appears with kvm, I never encountered this when using -no-kvm, or when using qemu w/ kqemu. * this problem also occured when running a Solaris 10 guest OS dmesg output during lockup below. See also kerneloops entry: http://kerneloops.org/guilty.php?guilty=apic_mmio_readversion=2.6.26-releasestart=1736704end=1769471class=oops [12518.803078] loaded kvm module (kvm-76) [12564.289154] kvm: emulating exchange as write [13926.593155] kvm: inject_page_fault: double fault 0x80c0bfa8 [14015.554904] BUG: soft lockup - CPU#1 stuck for 61s! [qemu-system-x86:20613] [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] CPU 1: [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] Pid: 20613, comm: qemu-system-x86 Tainted: P 2.6.26-1-amd64 #1 [14015.554904] RIP: 0010:[a0c0fa32] [a0c0fa32] :kvm:apic_mmio_read+0xf0/0x17d [14015.554904] RSP: 0018:81000821dc88 EFLAGS: 0202 [14015.554904] RAX: 62126c0cf17912e9 RBX: 0390 RCX: 62126c0cf2841a1b [14015.554904] RDX: 010b0732 RSI: 010b0732 RDI: fef4f8ce [14015.554904] RBP: fee0017b R08: 0001 R09: 0c12 [14015.554904] R10: R11: a0c60c5b R12: 000380281e01 [14015.554904] R13: 00c18dc0 R14: 0003 R15: 809b8390 [14015.554904] FS: 420ce950() GS:81012fa7c8c0() knlGS: [14015.554904] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [14015.554904] CR2: CR3: 91b53000 CR4: 26e0
Re: [kvm] Re: [PATCH 0/5] bios: 4G updates
Avi Kivity wrote: Avi Kivity wrote: I tried to merge it, but it the new bios won't boot. I traced this to ata_reset: it toggles the soft reset bit in the command register and expects to see the busy bit set, but the ide device model returns zero status if the selected device has no drive. No idea if the device model or the bios is wrong. If anyone (hi Gleb) wants to take a look, it's in the branch bios-merge on git.kernel.org. btw, commenting this out leads to boot failure as well, but that may be related. Okay, I think I have it -- the bios code was using .org to set certain entry points to well known addresses, and one code section overflowed due to enabling the cache, which is a kvm addition. Moving that bit out-of-line allows the bios to boot. It works, so I pushed it out. Alex, can you rebase your bios patches on top of current HEAD? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Fix enhance NMI support for KVM - v4
[EMAIL PROTECTED] wrote: Version 4 of this series includes the following fixes: - Handle NMI task gates (Gleb Natapov) - Clear internal NMI states on VCPU reset (Gleb Natapov) - Typo fixes and minor cleanups (Sheng Yang and /me) Hope we are now reaching a mergable state. Applied all, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops register interface
On Tue, Sep 30, 2008 at 05:38:15PM +0200, Ingo Molnar wrote:
* Muli Ben-Yehuda [EMAIL PROTECTED] wrote:
+static int calgary_device_supported(struct device *dev)
+{
+ return translation_enabled(find_iommu_table(dev));
+}
Sure, but I prefer the explicit form since it lends itself to easier
debugging (oops line numbers, adding printks, etc.).
we never do that for simple stuff like this. The kernel would be
twice as large if we did.
I assume you are talking about the source size, because the generated
code size should be exactly the same.
In any case, arguing where to place the semi-colon is a waste of
time. Do as you see fit.
Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
xxx
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops
On Mon, Sep 29, 2008 at 03:33:11PM +0200, Joerg Roedel wrote: Nobody cares about the performance of dma_alloc_coherent. Only the performance of map_single/map_sg matters. I'm not sure how expensive the hypercalls are, but they are more expensive than bounce buffering coping lots of data for every I/Os? I don't think that we can avoid bounce buffering into the guests at all (with and without my idea of a paravirtualized IOMMU) when we want to handle dma_masks and requests that cross guest physical pages properly. It might be possible to have a per-device slow or fast path, where the fast path is for devices which have no DMA limitations (high-end devices generally don't) and the slow path is for devices which do. With mapping/unmapping through hypercalls we add the world-switch overhead to the copy-overhead. We can't avoid this when we have no hardware support at all. But already with older IOMMUs like Calgary and GART we can at least avoid the world-switch. And since, for example, every 64 bit capable AMD processor has a GART we can make use of it. It should be possible to reduce the number and overhead of hypercalls to the point where their cost is immaterial. I think that's fundamentally a better approach. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] [PATCH 1/4] kvm: bios: cleanup/consolidate above 4G memory parsing
kvm: bios: cleanup/consolidate above 4G memory parsing
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
---
Updated for current HEAD after bochs bios re-base. The rest of the
patches in this series still apply cleanly.
bios/rombios32.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/bios/rombios32.c b/bios/rombios32.c
index befebb9..bb33cb3 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -416,7 +416,7 @@ uint32_t cpuid_signature;
uint32_t cpuid_features;
uint32_t cpuid_ext_features;
unsigned long ram_size;
-uint64_t above4g_ram_size;
+uint64_t ram_end;
uint8_t bios_uuid[16];
#ifdef BX_USE_EBDA_TABLES
unsigned long ebda_cur_addr;
@@ -531,9 +531,9 @@ void setup_mtrr(void)
wrmsr_smp(MTRRphysMask_MSR(i), (~vmask 0xfff000ull) | 0x800);
vbase += vmask + 1;
}
-for (vbase = 1ull 32; i vcnt vbase above4g_ram_size; ++i) {
+for (vbase = 1ull 32; i vcnt vbase ram_end; ++i) {
vmask = (1ull 40) - 1;
-while (vbase + vmask + 1 above4g_ram_size)
+while (vbase + vmask + 1 ram_end)
vmask = 1;
wrmsr_smp(MTRRphysBase_MSR(i), vbase | 6);
wrmsr_smp(MTRRphysMask_MSR(i), (~vmask 0xfff000ull) | 0x800);
@@ -551,18 +551,19 @@ void ram_probe(void)
ram_size = (cmos_readb(0x17) | (cmos_readb(0x18) 8)) * 1024;
if (cmos_readb(0x5b) | cmos_readb(0x5c) | cmos_readb(0x5d))
-above4g_ram_size = ((uint64_t)cmos_readb(0x5b) 16) |
-((uint64_t)cmos_readb(0x5c) 24) | ((uint64_t)cmos_readb(0x5d)
32);
+ram_end = (((uint64_t)cmos_readb(0x5b) 16) |
+ ((uint64_t)cmos_readb(0x5c) 24) |
+ ((uint64_t)cmos_readb(0x5d) 32)) + (1ull 32);
+ else
+ram_end = ram_size;
- if (above4g_ram_size)
-above4g_ram_size += 1ull 32;
+ BX_INFO(end of ram=%ldMB\n, ram_end 20);
BX_INFO(ram_size=0x%08lx\n, ram_size);
#ifdef BX_USE_EBDA_TABLES
ebda_cur_addr = ((*(uint16_t *)(0x40e)) 4) + 0x380;
BX_INFO(ebda_cur_addr: 0x%08lx\n, ebda_cur_addr);
#endif
- BX_INFO(top of ram %ldMB\n, above4g_ram_size 20);
setup_mtrr();
}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] The commit message of r5364, the revision which basically exists because of your posts, was somehow butchered and as such doesn't include any references, i'm very sorry about that. The above line was there in the commit message editing buffer, but then i somehow screwed it all up, probably when trying to reformat stuff suffling text around. Once again, i'm sorry. [..snip..] -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 0/5] bios: 4G updates
On Tue, 2008-09-30 at 19:46 +0300, Avi Kivity wrote: Avi Kivity wrote: Okay, I think I have it -- the bios code was using .org to set certain entry points to well known addresses, and one code section overflowed due to enabling the cache, which is a kvm addition. Moving that bit out-of-line allows the bios to boot. It works, so I pushed it out. Alex, can you rebase your bios patches on top of current HEAD? I updated and resent the first patch in the 4 patch follow-on to this one. The remaining 3 patches still apply cleanly. I think Sheng was going to send out a patch to better follow the SDM when changing the MTRRs, but the first 3 patches are independent of that. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix compilation with --disable-kvm
Currently, kvm is failing to build with --disable-kvm.
this patch fixes the issue.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
qemu/gdbstub.c | 15 ++-
qemu/hw/acpi.c |6 +-
qemu/hw/cirrus_vga.c |7 +++
qemu/monitor.c |6 --
4 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/qemu/gdbstub.c b/qemu/gdbstub.c
index d57cd61..d65f1cf 100644
--- a/qemu/gdbstub.c
+++ b/qemu/gdbstub.c
@@ -994,10 +994,12 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
env-eip = addr;
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env-nip = addr;
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
#elif defined (TARGET_SPARC)
env-pc = addr;
env-npc = addr + 4;
@@ -1033,7 +1035,8 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
env-eip = addr;
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env-nip = addr;
kvm_load_registers(env);
@@ -1078,7 +1081,8 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
}
break;
case 'g':
-kvm_save_registers(env);
+if (kvm_enabled())
+kvm_save_registers(env);
reg_size = cpu_gdb_read_registers(env, mem_buf);
memtohex(buf, mem_buf, reg_size);
put_packet(s, buf);
@@ -1088,7 +1092,8 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
len = strlen(p) / 2;
hextomem((uint8_t *)registers, p, len);
cpu_gdb_write_registers(env, mem_buf, len);
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
put_packet(s, OK);
break;
case 'm':
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 05f5dc0..a51fcb7 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -726,7 +726,11 @@ void qemu_system_cpu_hot_add(int cpu, int state)
{
CPUState *env;
-if ((state) (!qemu_kvm_cpu_env(cpu))) {
+if (state
+#ifdef USE_KVM
+ (!qemu_kvm_cpu_env(cpu))
+#endif
+) {
env = pc_new_cpu(cpu, model, 1);
if (!env) {
fprintf(stderr, cpu %d creation failed\n, cpu);
diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index 4f3aef9..dac0731 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -2677,14 +2677,13 @@ static void kvm_update_vga_alias(CirrusVGAState *s, int
ok, int bank)
if (!s-aliases_enabled
|| base != s-aliased_bank_base[bank]
|| limit != s-aliased_bank_limit[bank]) {
- kvm_create_memory_alias(kvm_context,
- 0xa + bank * 0x8000,
- limit, base);
+ kvm_qemu_create_memory_alias(0xa + bank * 0x8000,
+ limit, base);
s-aliased_bank_base[bank] = base;
s-aliased_bank_limit[bank] = limit;
}
} else {
- kvm_destroy_memory_alias(kvm_context, 0xa + bank * 0x8000);
+ kvm_qemu_destroy_memory_alias(0xa + bank * 0x8000);
}
}
diff --git a/qemu/monitor.c b/qemu/monitor.c
index d6b3da6..97b5cbe 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -292,7 +292,8 @@ static CPUState *mon_get_cpu(void)
mon_set_cpu(0);
}
-kvm_save_registers(mon_cpu);
+if (kvm_enabled())
+kvm_save_registers(mon_cpu);
return mon_cpu;
}
@@ -320,7 +321,8 @@ static void do_info_cpus(void)
mon_get_cpu();
for(env = first_cpu; env != NULL; env = env-next_cpu) {
-kvm_save_registers(env);
+if (kvm_enabled())
+kvm_save_registers(env);
term_printf(%c CPU #%d:,
(env == mon_cpu) ? '*' : ' ',
env-cpu_index);
--
1.5.5.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] provide a kvm_qemu_memory_alias() function
Following the pattern we already do, provide a qemu_kvm wrapper to
the memory aliases x86 functions. Reason is that we don't want to have
references to the context spread over qemu.
The destroy alias function is completely removed from libkvm/libkvm.c,
since no one in the code base uses it directly.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c |5 -
qemu/qemu-kvm-x86.c | 12
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index a8cca15..f33038d 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -206,11 +206,6 @@ int kvm_create_memory_alias(kvm_context_t kvm,
return 0;
}
-int kvm_destroy_memory_alias(kvm_context_t kvm, uint64_t phys_start)
-{
- return kvm_create_memory_alias(kvm, phys_start, 0, 0);
-}
-
#ifdef KVM_CAP_IRQCHIP
int kvm_get_lapic(kvm_context_t kvm, int vcpu, struct kvm_lapic_state *s)
diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c
index 5daedd1..55c520d 100644
--- a/qemu/qemu-kvm-x86.c
+++ b/qemu/qemu-kvm-x86.c
@@ -27,6 +27,18 @@ static int kvm_has_msr_star;
static int lm_capable_kernel;
+int kvm_qemu_create_memory_alias(uint64_t phys_start,
+ uint64_t len,
+ uint64_t target_phys)
+{
+return kvm_create_memory_alias(kvm_context, phys_start, len, target_phys);
+}
+
+int kvm_qemu_destroy_memory_alias(uint64_t phys_start)
+{
+ return kvm_create_memory_alias(kvm_context, phys_start, 0, 0);
+}
+
int kvm_arch_qemu_create_context(void)
{
int i;
--
1.5.5.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] --disable-kvm currently not working
Current compilations with --disable-kvm are broken. I'm spliting the fix in two patches for clearity. The first one does some code movement in qemu-kvm-x86.c, while the other just do fixes to the current code base. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] --disable-kvm currently not working
On Tue, Sep 30, 2008 at 6:47 PM, Glauber Costa [EMAIL PROTECTED] wrote: Current compilations with --disable-kvm are broken. I'm spliting the fix in two patches for clearity. The first one does some code movement in qemu-kvm-x86.c, while the other just do fixes to the current code base. oh god, forgot to do format-patch -n _again_ ;-( avi, should I resend? Since there are only two of them , it's pretty straightforward. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6 v3] PCI: support ARI capability
* Zhao, Yu [EMAIL PROTECTED]:
Add Alternative Routing-ID Interpretation (ARI) support.
Cc: Jesse Barnes [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
Cc: Grant Grundler [EMAIL PROTECTED]
Cc: Alex Chiang [EMAIL PROTECTED]
Cc: Matthew Wilcox [EMAIL PROTECTED]
Cc: Roland Dreier [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Signed-off-by: Yu Zhao [EMAIL PROTECTED]
---
drivers/pci/pci.c| 31 +++
drivers/pci/pci.h| 12
drivers/pci/probe.c |3 +++
include/linux/pci.h |1 +
include/linux/pci_regs.h | 14 ++
5 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 400d3b3..fe9efc4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1260,6 +1260,37 @@ void pci_pm_init(struct pci_dev *dev)
}
}
+/**
+ * pci_ari_init - turn on ARI forwarding if it's supported
+ * @dev: the PCI device
+ */
+void pci_ari_init(struct pci_dev *dev)
+{
+ int pos;
+ u32 cap;
+ u16 ctrl;
+
+ if (!dev-is_pcie || (dev-pcie_type != PCI_EXP_TYPE_ROOT_PORT
+ dev-pcie_type != PCI_EXP_TYPE_DOWNSTREAM))
+ return;
+
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (!pos)
+ return;
+
+ pci_read_config_dword(dev, pos + PCI_EXP_DEVCAP2, cap);
+
+ if (!(cap PCI_EXP_DEVCAP2_ARI))
+ return;
+
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCTL2, ctrl);
+ ctrl |= PCI_EXP_DEVCTL2_ARI;
+ pci_write_config_word(dev, pos + PCI_EXP_DEVCTL2, ctrl);
+
+ dev-ari_enabled = 1;
+ dev_info(dev-dev, ARI forwarding enabled.\n);
This is user-visible, so my questions are:
1) Does this really add value for the user? Or is this
just more noise?
2) Is this output string informative enough for the user?
Thanks.
/ac
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6 v3] PCI: support SR-IOV capability
* Zhao, Yu [EMAIL PROTECTED]:
+/**
+ * pci_iov_init - initialize device's SR-IOV capability
+ * @dev: the PCI device
+ *
+ * Returns 0 on success, or negative on failure.
+ *
+ * The major differences between Virtual Function and PCI device are:
+ * 1) the device with multiple bus numbers uses internal routing, so
+ *there is no explicit bridge device in this case.
+ * 2) Virtual Function memory spaces are designated by BARs encapsulated
+ *in the capability structure, and the BARs in Virtual Function PCI
+ *configuration space are read-only zero.
+ */
+int pci_iov_init(struct pci_dev *dev)
+{
+ int i;
+ int pos;
+ u32 pgsz;
+ u16 ctrl, total, initial, offset, stride;
+ struct pci_iov *iov;
+ struct resource *res;
+
+ if (!dev-is_pcie || (dev-pcie_type != PCI_EXP_TYPE_RC_END
+ dev-pcie_type != PCI_EXP_TYPE_ENDPOINT))
+ return -ENODEV;
+
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_IOV);
+ if (!pos)
+ return -ENODEV;
+
+ ctrl = pci_ari_enabled(dev) ? PCI_IOV_CTRL_ARI : 0;
+ pci_write_config_word(dev, pos + PCI_IOV_CTRL, ctrl);
+ ssleep(1);
+
+ pci_read_config_word(dev, pos + PCI_IOV_TOTAL_VF, total);
+ pci_read_config_word(dev, pos + PCI_IOV_INITIAL_VF, initial);
+ pci_write_config_word(dev, pos + PCI_IOV_NUM_VF, initial);
+ pci_read_config_word(dev, pos + PCI_IOV_VF_OFFSET, offset);
+ pci_read_config_word(dev, pos + PCI_IOV_VF_STRIDE, stride);
+ if (!total || initial total || (initial !offset) ||
+ (initial 1 !stride))
+ return -EIO;
+
+ pci_read_config_dword(dev, pos + PCI_IOV_SUP_PGSIZE, pgsz);
+ i = PAGE_SHIFT 12 ? PAGE_SHIFT - 12 : 0;
+ pgsz = ~((1 i) - 1);
+ if (!pgsz)
+ return -EIO;
+
+ pgsz = ~(pgsz - 1);
+ pci_write_config_dword(dev, pos + PCI_IOV_SYS_PGSIZE, pgsz);
+
+ iov = kzalloc(sizeof(*iov), GFP_KERNEL);
+ if (!iov)
+ return -ENOMEM;
+
+ iov-dev = dev;
+ iov-cap = pos;
+ iov-totalvfs = total;
+ iov-initialvfs = initial;
+ iov-offset = offset;
+ iov-stride = stride;
+ iov-align = pgsz 12;
+ mutex_init(iov-mutex);
+
+ for (i = 0; i PCI_IOV_NUM_BAR; i++) {
+ res = dev-resource + PCI_IOV_RESOURCES + i;
+ pos = iov-cap + PCI_IOV_BAR_0 + i * 4;
+ i += pci_read_base(dev, pci_bar_unknown, res, pos);
+ if (!res-flags)
+ continue;
+ res-flags = ~IORESOURCE_SIZEALIGN;
+ res-end = res-start + resource_size(res) * total - 1;
+ }
+
+ dev-iov = iov;
+ dev_info(dev-dev, SR-IOV capability is initialized\n);
Same questions here that I had for the ARI stuff. Does this
dev_info add value, or is it more noise, and is this message
informative enough?
+
+ return 0;
+}
+
+/**
+ * pci_iov_release - release resources used by SR-IOV capability
+ * @dev: the PCI device
+ */
+void pci_iov_release(struct pci_dev *dev)
+{
+ if (!dev-iov)
+ return;
+
+ mutex_destroy(dev-iov-mutex);
+ kfree(dev-iov);
+ dev-iov = NULL;
+}
+
+/**
+ * pci_iov_create_sysfs - create sysfs for SR-IOV capability
+ * @dev: the PCI device
+ */
+void pci_iov_create_sysfs(struct pci_dev *dev)
+{
+ int rc;
+ int i, j;
+ struct pci_iov *iov = dev-iov;
+
+ if (!iov)
+ return;
+
+ iov-ve = kzalloc(sizeof(*iov-ve) * iov-totalvfs, GFP_KERNEL);
+ if (!iov-ve)
+ return;
+
+ for (i = 0; i iov-totalvfs; i++) {
+ iov-ve[i].vfn = i;
+ iov-ve[i].iov = iov;
+ }
+
+ rc = kobject_init_and_add(iov-kobj, iov_ktype,
+ dev-dev.kobj, iov);
+ if (rc)
+ goto failed1;
+
+ for (i = 0; i ARRAY_SIZE(iov_attr); i++) {
+ rc = sysfs_create_file(iov-kobj, iov_attr[i].attr);
+ if (rc)
+ goto failed2;
+ }
+
+ for (i = 0; i iov-totalvfs; i++) {
+ sprintf(iov-ve[i].name, %d, i);
+ rc = kobject_init_and_add(iov-ve[i].kobj, iov_ktype,
+ iov-kobj, iov-ve[i].name);
+ if (rc)
+ goto failed3;
+ rc = sysfs_create_file(iov-ve[i].kobj, vf_attr.attr);
+ if (rc) {
+ kobject_put(iov-ve[i].kobj);
+ goto failed3;
+ }
+ }
Do you want to emit a kobject_uevent here after success?
Alternatively, have you investigated making these virtual
functions into real struct device's? You get a lot of sysfs stuff
for free if you do
Re: [PATCH 4/6 v3] PCI: support SR-IOV capability
+ ctrl = pci_ari_enabled(dev) ? PCI_IOV_CTRL_ARI : 0; + pci_write_config_word(dev, pos + PCI_IOV_CTRL, ctrl); + ssleep(1); You seem to sleep for 1 second wherever you write the IOV_CTRL register. Why is this? Is this specified by PCI, or is it coming from somewhere else? - R. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
freebsd 7.0 32-bit won't boot with kvm scsi
I am attempting to get freebsd 7.0 32-bit running under kvm-76 and have been successful with the emulated ide interface and e1000 networking. When I try to use kvm's scsi interface, I am able to complete the freebsd install but get a bootloader message stating that the kernel cannot be found upon attempting to boot into freebsd. Has anyone else experienced this? Thanks, Sterling Windmill -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] kvm-userspace: kvmppc: fix build for ppc v2
From: Christian Ehrhardt [EMAIL PROTECTED] *update Short after resending v1 I realized that I forgot to put Avi and [EMAIL PROTECTED] (for 2/3) on cc. I also updated the header text in 1/3 a bit and verified my hostlongbits proposal on recent cross toolchain versions because there was a question about that. Updating and testing kvm-userspace for ppc after a too long time brought up some issues fixed in this series. The patches are small and their description should be comprehendible. Due to the fact that most of the issues where build time issues I also started to discuss about/establish some kind of automated build test for us that should allow us to find such things faster. Let me know if qumranet has such a process for x86 already and I should help you to include powerpc. [patches in series] [PATCH 1/3] kvm-userspace: kvmppc: fix file header in libkvm-powerpc.c [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling [PATCH 3/3] kvm-userspace: kvmppc: fix building userspace for powerpc --- [diffstat] Makefile |3 ++- kernel/powerpc/Makefile.pre|1 + kernel/powerpc/hack-module.awk |5 + libkvm/libkvm-powerpc.c| 14 +- qemu/Makefile.target |2 +- qemu/configure | 13 +++-- 6 files changed, 21 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling
From: Christian Ehrhardt [EMAIL PROTECTED]
A recent kvm merge with qemu brought code for 64bit power that broke cross
compilation. The issue is caused by configure trying to execute target
architecture binaries where configure is executed.
I tried to change that detection so that it works withwithout cross
compilation with only a small change and especially without an addtional
configure command line switch. Including the bits/wordsize.h header a platform
usually can check its wordsize and by doing that configure can check the
hostlongbits without executing the binary. Instead it now stops after
preprocessing stage which resolved the __WORDSIZE constant and retrieves
that value.
I don't like my new check style, but it is at least less broken than before.
Another approach that was suggested was that qemu might end up needing
something like asm-offsets in the kernel to manage architecture sizes etc.
Comments and other approaches welcome.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
configure | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
[diff]
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -685,14 +685,15 @@
# ppc specific hostlongbits selection
if test $cpu = powerpc ; then
cat $TMPC EOF
-int main(void){return sizeof(long);}
+#include bits/wordsize.h
+__WORDSIZE
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null; then
-$TMPE
-case $? in
-4) hostlongbits=32;;
-8) hostlongbits=64;;
+if $cc $ARCH_CFLAGS -E -o $TMPE.E $TMPC 2 /dev/null; then
+wordsize=`tail -n 1 ${TMPE}.E`
+case $wordsize in
+32) hostlongbits=32;;
+64) hostlongbits=64;;
*) echo Couldn't determine bits per long value; exit 1;;
esac
else
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
