Re: [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops
On Sun, Sep 28, 2008 at 08:44:24PM +0200, Joerg Roedel wrote: Hmm, we should only call find_dma_ops_for_device() the first time a dma api call is done (look into get_dma_ops). But I also thought about how this lock can be avoided. In the real world it should not be necessary because the dma_ops list is initialized before dma api calls are done. But since there is now a register function which can be called its safer this way. What do you think, are we still safe enough without this lock? We could be, if we add a check to the register function that verifies it isn't being called after DMAs have started. Something like: in register: if (dma_started) yell loudly before PCI device initialization and after IOMMU initialization: dma_started = true 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 12:25:49PM +0300, Muli Ben-Yehuda wrote: On Sun, Sep 28, 2008 at 08:44:24PM +0200, Joerg Roedel wrote: Hmm, we should only call find_dma_ops_for_device() the first time a dma api call is done (look into get_dma_ops). But I also thought about how this lock can be avoided. In the real world it should not be necessary because the dma_ops list is initialized before dma api calls are done. But since there is now a register function which can be called its safer this way. What do you think, are we still safe enough without this lock? We could be, if we add a check to the register function that verifies it isn't being called after DMAs have started. Something like: in register: if (dma_started) yell loudly before PCI device initialization and after IOMMU initialization: dma_started = true Good idea. I will change this in my patchset, thanks. Joerg -- 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 12:30:44PM +0300, Muli Ben-Yehuda wrote: On Sun, Sep 28, 2008 at 09:13:33PM +0200, Joerg Roedel wrote: I think we should try to build a paravirtualized IOMMU for KVM guests. It should work this way: We reserve a configurable amount of contiguous guest physical memory and map it dma contiguous using some kind of hardware IOMMU. This is possible with all hardare IOMMUs we have in the field by now, also Calgary and GART. The guest does dma_coherent allocations from this memory directly and is done. For map_single and map_sg the guest can do bounce buffering. We avoid nearly all pvdma hypercalls with this approach, keep guest swapping working and solve also the problems with device dma_masks and guest memory that is not contigous on the host side. I'm not sure I follow, but if I understand correctly with this approach the guest could only DMA into buffers that fall within the range you allocated for DMA and mapped. Isn't that a pretty nasty limitation? The guest would need to bounce-bufer every frame that happened to not fall inside that range, with the resulting loss of performance. The bounce buffering is needed for map_single/map_sg allocations. For dma_alloc_coherent we can directly allocate from that range. The performance loss of the bounce buffering may be lower than the hypercalls we need as the alternative (we need hypercalls for map, unmap and sync). Joerg -- 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
unhandled vm exit: 0x80000021 vcpu_id 0
Hi, I have successfully installed windows XP SP2 on kvm. After the installation I have launched the setup of Checkpoint - Pointsec for the entire disk encryption. The first step of installation was run successfully, but when the system reboots and Pointsec loads the initial code, the following error happens: == unhandled vm exit: 0x8021 vcpu_id 0 rax 0007 rbx 1490 rcx rdx 19a0 rsi rdi rsp 0080 rbp 96bf r8 r9 r10 r11 r12 r13 r14 r15 rip 002a rflags 00023202 cs 14a2 (/ p 0 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) ds 19a0 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es 1a31 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 1a29 (/ p 0 dpl 0 db 0 s 0 type 1 l 0 g 0 avl 0) fs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0058 (00201ffa/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 20/1dd8 idt 201df0/188 cr0 8019 cr2 0 cr3 144 cr4 0 cr8 0 efer 0 Aborted == I am able to boot this system (image) using qemu (with kqemu enabled for user code), but not using kvm. I have also tried with the options: -no-kvm-irqchip -no-kvm-pit -no- acpi without success. Only the -no-kvm option works. I have tried these kvm releases: from 65 to 76; and these kernel (vanilla) releases: from 2.6.23.1 to 2.6.26.5. My computer is a Dell D630 equipped with Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz The HOST Linux distributions used are: Fedora 8/9 for i386, and Fedora 9 for x86_64. Regards, Pier Luigi Con Tiscali Adsl 8 Mega navighi SENZA LIMITI e GRATIS PER I PRIMI TRE MESI. In seguito paghi solo € 19,95 al mese. Attivala ora, l?offerta è valida fino al 02/10/2008! http://abbonati.tiscali.it/promo/adsl8mega/ -- 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-76 --std-vga problem
I can confirm problems with --std-vga.
I had 4 running win xp sp3 guest with --std-vga (KVM-75).
Now, after upgrading to KVM-76 the screen goes black, just before the welcome
and hangs.
Im using a 2.6.24 kernel (Debian 64)
Best Regards,
Martin Maurer
[EMAIL PROTECTED]
http://www.proxmox.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Malone
Sent: Sonntag, 28. September 2008 23:45
To: kvm mailing list
Subject: kvm-76 --std-vga problem
Hi Everyone,
I just downloaded and ran the new kvm-76 (upgrading from kvm-74) and I
have a few issues.
I am running Ubuntu 8.04 (Hardy) as my host and Windows XP as my guest.
I am using VT-d and the kernel modules loaded correctly.
Here is the command I use to start kvm:
kvm-bridge -hda windows2.img -boot c -m 1000 -serial /dev/ttyUSB0
-serial file:serial.out -smp 2 -usb -usbdevice tablet -full-screen
-cdrom /dev/cdrom
kvm-bridge is a script that configures my network and passes the other
options straight through to qemu-system-x86_64
1) what is the difference between running qemu-system-x86_64 and kvm
directly?
Because, when I run kvm directly, I get this error:
Traceback (most recent call last):
File /home/malonem/kvm-76/kvm, line 20, in module
external_module = config.get('shell', 'want_module')
File /usr/lib/python2.5/ConfigParser.py, line 511, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'shell'
2) (this has been around for quite some time, I just haven't done
anything about it)
Even though I start up with -smp 2, windows only reads 1 cpu
3) When I run it using the --std-vga parameter, windows boots to just
before it gets to the welcome screen and hangs. The output shows a
multitude of kvm: get_dirty_pages returned -2 Is this something to do
with the kernel version I am using? I am using the standard Ubuntu
Hardy Kernel 2.6.24-19-generic. I read the release notes about the
kernel version with kvm-76 but didn't really understand them and
presumed that I am using the kernel modules supplied with kvm. (I
rmmod'd kvm-intel and kvm before I compiled and installed, then
modprobe'd the modules afterwards and everything seemed to go ok)
Any help or insight would be much appreciated,
Michael
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
--
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
--
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][RESEND] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling
From: Christian Ehrhardt [EMAIL PROTECTED]
The 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 that check style, but it is at least less broken than before.
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][RESEND] 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
Re: kvm-76 --std-vga problem
On Sunday 28 September 2008 4:44:30 pm Michael Malone wrote:
Hi Everyone,
I just downloaded and ran the new kvm-76 (upgrading from kvm-74) and I
have a few issues.
I am running Ubuntu 8.04 (Hardy) as my host and Windows XP as my guest.
I am using VT-d and the kernel modules loaded correctly.
Here is the command I use to start kvm:
kvm-bridge -hda windows2.img -boot c -m 1000 -serial /dev/ttyUSB0
-serial file:serial.out -smp 2 -usb -usbdevice tablet -full-screen
-cdrom /dev/cdrom
kvm-bridge is a script that configures my network and passes the other
options straight through to qemu-system-x86_64
1) what is the difference between running qemu-system-x86_64 and kvm
directly?
Because, when I run kvm directly, I get this error:
Traceback (most recent call last):
File /home/malonem/kvm-76/kvm, line 20, in module
external_module = config.get('shell', 'want_module')
File /usr/lib/python2.5/ConfigParser.py, line 511, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'shell'
That's a python qemu wrapper (which is unfortunately named kvm). That is not
the same as the kvm binary which most distros install. You'll want to use the
qemu-system-x86_64 binary in the qemu/x86_64-softmmu dir if you want to run
directly from the source dir. But it looks like you've already installed it
to the system, so I wouldn't bother.
2) (this has been around for quite some time, I just haven't done
anything about it)
Even though I start up with -smp 2, windows only reads 1 cpu
You probably installed the guest with -smp 1. In which case, XP would have
installed the Uniprocessor HAL. You'd have to change that out or reinstall
the guest to be able to use more than one CPU.
3) When I run it using the --std-vga parameter, windows boots to just
before it gets to the welcome screen and hangs. The output shows a
multitude of kvm: get_dirty_pages returned -2 Is this something to do
with the kernel version I am using? I am using the standard Ubuntu
Hardy Kernel 2.6.24-19-generic. I read the release notes about the
kernel version with kvm-76 but didn't really understand them and
presumed that I am using the kernel modules supplied with kvm. (I
rmmod'd kvm-intel and kvm before I compiled and installed, then
modprobe'd the modules afterwards and everything seemed to go ok)
I don't know about this, but it seems that someone else verified, so hopefully
the devs will be on it soon.
Any help or insight would be much appreciated,
Michael
--
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][RESEND] kvm-userspace: kvmppc: fix file header in libkvm-powerpc.c
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 + * Added by: * 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 0/3][RESEND] kvm-userspace: kvmppc: fix build for ppc
From: Christian Ehrhardt [EMAIL PROTECTED] * I got neither pro/con comments nor an accepted message - resend 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
Weekly KVM Test report, kernel 9b8f754c ... userspace 35bf248e ...
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 9b8f754c6c84210617baed4d99b36c2e413f68ad and kvm-userspace.git 35bf248ec594035d3d23665fedf46c85f329f171. There is no new issue found this week. Fixed issue: 1. Can not build KVM with 2.6.26 kernel https://sourceforge.net/tracker/index.php?func=detailaid=2119399group_id=180599atid=893831 Four Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 3. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detailaid=2088475group_id=180599atid=893831 4. Fail to save restore and live migration https://sourceforge.net/tracker/index.php?func=detailaid=2106661group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G' Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 8 5 3 00 Restart 2 2 0 00 gtest 15 11 4 00 = control_panel 8 5 3 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_two_winxp_PAE_gPAE1 1 0 00 :KVM_four_sguest_PAE_gPA 1 1 0 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_LM_Continuity_PAE_g 1 0 1 00 :KVM_LM_SMP_PAE_gPAE 1 0 1 00 :KVM_SR_Continuity_PAE_g 1 0 1 00 Restart 2 2 0 00 :GuestPAE_PAE_g32e 1 1 0 00 :BootTo32pae_PAE_g32e 1 1 0 00 gtest 15 11 4 00 :ltp_nightly_PAE_gPAE 1 1 0 00 :boot_up_acpi_PAE_gPAE 1 1 0 00 :boot_up_acpi_xp_PAE_gPA 1 0 1 00 :boot_up_vista_PAE_gPAE1 0 1 00 :reboot_xp_PAE_gPAE1 1 0 00 :boot_base_kernel_PAE_gP 1 1 0 00 :boot_up_acpi_win2k3_PAE 1 0 1 00 :boot_smp_acpi_win2k3_PA 1 1 0 00 :boot_smp_acpi_win2k_PAE 1 1 0 00 :boot_up_acpi_win2k_PAE_ 1 0 1 00 :boot_smp_acpi_xp_PAE_gP 1 1 0 00 :boot_up_noacpi_win2k_PA 1 1 0 00 :boot_smp_vista_PAE_gPAE 1 1 0 00 :bootx_PAE_gPAE1 1 0 00 :kb_nightly_PAE_gPAE 1 1 0 00 = Total 25 18 7 00 Report Summary on IA32e Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 18 10 8 00 gtest 23 23 0 00 = control_panel 18 10 8 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 0 1 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 0 1
Re: [PATCH 0/9][RFC] stackable dma_ops for x86
On Sun, 28 Sep 2008 20:49:26 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 11:21:26PM +0900, FUJITA Tomonori wrote: On Mon, 22 Sep 2008 20:21:12 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: Hi, this patch series implements stackable dma_ops on x86. This is useful to be able to fall back to a different dma_ops implementation if one can not handle a particular device (as necessary for example with paravirtualized device passthrough or if a hardware IOMMU only handles a subset of available devices). We already handle the latter. This patchset is more flexible but seems to incur more overheads. This feature will be used for only paravirtualized device passthrough? If so, I feel that there is more simpler (and specific) solutions for it. Its not only for device passthrough. It handles also the cases where a hardware IOMMU does not handle all devices in the system (like in some Calgary systems but also possible with AMD IOMMU). With this patchset we I know that. As I wrote in the previous mail, we already solved that problem with per-device-dma-ops. My question is what unsolved problems this patchset can fix? This patchset is named stackable dma_ops but it's different from what we discussed as stackable dma_ops. This patchset provides IOMMUs a generic mechanism to set up stackable dma_ops. But this patchset doesn't solve the problem that a hardware IOMMU does not handle all devices (it was already solved with per-device-dma-ops). If paravirtualized device passthrough still needs to call multiple dma_ops, then this patchset doesn't solve that issue. can handle these cases in a generic way without hacking it into the hardware drivers (these hacks are also in the AMD IOMMU code and I plan to remove them in the case this patchset will be accepted). -- 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, 29 Sep 2008 11:36:52 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30:44PM +0300, Muli Ben-Yehuda wrote: On Sun, Sep 28, 2008 at 09:13:33PM +0200, Joerg Roedel wrote: I think we should try to build a paravirtualized IOMMU for KVM guests. It should work this way: We reserve a configurable amount of contiguous guest physical memory and map it dma contiguous using some kind of hardware IOMMU. This is possible with all hardare IOMMUs we have in the field by now, also Calgary and GART. The guest does dma_coherent allocations from this memory directly and is done. For map_single and map_sg the guest can do bounce buffering. We avoid nearly all pvdma hypercalls with this approach, keep guest swapping working and solve also the problems with device dma_masks and guest memory that is not contigous on the host side. I'm not sure I follow, but if I understand correctly with this approach the guest could only DMA into buffers that fall within the range you allocated for DMA and mapped. Isn't that a pretty nasty limitation? The guest would need to bounce-bufer every frame that happened to not fall inside that range, with the resulting loss of performance. The bounce buffering is needed for map_single/map_sg allocations. For dma_alloc_coherent we can directly allocate from that range. The performance loss of the bounce buffering may be lower than the hypercalls we need as the alternative (we need hypercalls for map, unmap and sync). 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? -- 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/9][RFC] stackable dma_ops for x86
On Mon, Sep 29, 2008 at 10:16:39PM +0900, FUJITA Tomonori wrote: On Sun, 28 Sep 2008 20:49:26 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 11:21:26PM +0900, FUJITA Tomonori wrote: On Mon, 22 Sep 2008 20:21:12 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: Hi, this patch series implements stackable dma_ops on x86. This is useful to be able to fall back to a different dma_ops implementation if one can not handle a particular device (as necessary for example with paravirtualized device passthrough or if a hardware IOMMU only handles a subset of available devices). We already handle the latter. This patchset is more flexible but seems to incur more overheads. This feature will be used for only paravirtualized device passthrough? If so, I feel that there is more simpler (and specific) solutions for it. Its not only for device passthrough. It handles also the cases where a hardware IOMMU does not handle all devices in the system (like in some Calgary systems but also possible with AMD IOMMU). With this patchset we I know that. As I wrote in the previous mail, we already solved that problem with per-device-dma-ops. My question is what unsolved problems this patchset can fix? This patchset is named stackable dma_ops but it's different from what we discussed as stackable dma_ops. This patchset provides IOMMUs a generic mechanism to set up stackable dma_ops. But this patchset doesn't solve the problem that a hardware IOMMU does not handle all devices (it was already solved with per-device-dma-ops). If paravirtualized device passthrough still needs to call multiple dma_ops, then this patchset doesn't solve that issue. Ok, the name stackable is misleading and was a bad choice. I will rename it to multiplexing. This should make it more clear what it is. Like you pointed out, the problems are solved with per-device dma_ops, but in the current implementation it needs special hacks in the IOMMU drivers to use these per-device dma_ops. I see this patchset as a continuation of the per-device dma_ops idea. It moves the per-device handling out of the specific drivers to a common place. So we can avoid or remove special hacks in the IOMMU drivers. 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
Re: [PATCH 0/9][RFC] stackable dma_ops for x86
On Mon, 29 Sep 2008 15:26:47 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 10:16:39PM +0900, FUJITA Tomonori wrote: On Sun, 28 Sep 2008 20:49:26 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 11:21:26PM +0900, FUJITA Tomonori wrote: On Mon, 22 Sep 2008 20:21:12 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: Hi, this patch series implements stackable dma_ops on x86. This is useful to be able to fall back to a different dma_ops implementation if one can not handle a particular device (as necessary for example with paravirtualized device passthrough or if a hardware IOMMU only handles a subset of available devices). We already handle the latter. This patchset is more flexible but seems to incur more overheads. This feature will be used for only paravirtualized device passthrough? If so, I feel that there is more simpler (and specific) solutions for it. Its not only for device passthrough. It handles also the cases where a hardware IOMMU does not handle all devices in the system (like in some Calgary systems but also possible with AMD IOMMU). With this patchset we I know that. As I wrote in the previous mail, we already solved that problem with per-device-dma-ops. My question is what unsolved problems this patchset can fix? This patchset is named stackable dma_ops but it's different from what we discussed as stackable dma_ops. This patchset provides IOMMUs a generic mechanism to set up stackable dma_ops. But this patchset doesn't solve the problem that a hardware IOMMU does not handle all devices (it was already solved with per-device-dma-ops). If paravirtualized device passthrough still needs to call multiple dma_ops, then this patchset doesn't solve that issue. Ok, the name stackable is misleading and was a bad choice. I will rename it to multiplexing. This should make it more clear what it is. Like you pointed out, the problems are solved with per-device dma_ops, but in the current implementation it needs special hacks in the IOMMU drivers to use these per-device dma_ops. I see this patchset as a continuation of the per-device dma_ops idea. It moves the per-device handling out of the specific drivers to a common place. So we can avoid or remove special hacks in the IOMMU drivers. Basically, I'm not against this patchset. It simplify Calgary and AMD IOMMUs code to set up per-device-dma-ops (though it makes dma_ops a bit complicated). But it doesn't solve any problems including the paravirtualized device passthrough. When I wrote per-device-dma-ops, I expected that KVM people want more changes (such as stackable dma_ops) to dma_ops for the paravirtualized device passthrough. I'd like to hear what they want first. -- 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-2063072 ] compiling problem with tcg_ctx
Bugs item #2063072, was opened at 2008-08-20 17:29
Message generated for change (Comment added) made by aliguori
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2063072group_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: Jana Delego (janado)
Assigned to: Anthony Liguori (aliguori)
Summary: compiling problem with tcg_ctx
Initial Comment:
When compiling kvm using the --disable-cpu-emulation flag on a 64 bit Intel
Ubuntu, the compiler aborts with error undefined reference to tcg_ctx,
This problem exists since kvm-70.
--
Comment By: Anthony Liguori (aliguori)
Date: 2008-09-29 09:56
Message:
--disable-cpu-emulation should not be used with x86. It only exists as an
ugly hack because ia64 doesn't support TCG.
--
Comment By: Shen Okinudo (okinu)
Date: 2008-09-28 21:37
Message:
This bug persists in kvm-76
--
Comment By: Marshal Newrock (freedombi)
Date: 2008-09-01 19:40
Message:
Logged In: YES
user_id=2201280
Originator: NO
This seems to work with kvm-74. The patch allowed compilation, and the
guest appears to be running well.
--
Comment By: Amit Shah (amitshah)
Date: 2008-08-29 05:59
Message:
Logged In: YES
user_id=201894
Originator: NO
I'm not sure if this will make qemu work properly, but it fixes the build
(also attached). Can you confirm if this works?
commit 244cafe6688940c25c81b31aa223c9e24656806e
Author: Amit Shah [EMAIL PROTECTED]
Date: Fri Aug 29 15:20:14 2008 +0530
KVM: QEMU: Fix userspace build with --disable-cpu-emulation
I'm not sure this will work properly, but fixes the build.
ppc might need something like this as well
Signed-off-by: Amit Shah [EMAIL PROTECTED]
diff --git a/qemu/target-i386/fake-exec.c b/qemu/target-i386/fake-exec.c
index 737286d..552089b 100644
--- a/qemu/target-i386/fake-exec.c
+++ b/qemu/target-i386/fake-exec.c
@@ -12,6 +12,13 @@
*/
#include exec.h
#include cpu.h
+#include tcg.h
+
+/* code generation context */
+TCGContext tcg_ctx;
+
+uint16_t gen_opc_buf[OPC_BUF_SIZE];
+TCGArg gen_opparam_buf[OPPARAM_BUF_SIZE];
int code_copy_enabled = 0;
@@ -45,10 +52,6 @@ int cpu_x86_gen_code(CPUState *env, TranslationBlock
*tb, int *gen_code_size_ptr
return 0;
}
-void flush_icache_range(unsigned long start, unsigned long stop)
-{
-}
-
void optimize_flags_init(void)
{
}
File Added: 0001-KVM-QEMU-Fix-userspace-build-with-disable-cpu-em.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2063072group_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 0/9][RFC] stackable dma_ops for x86
On Mon, Sep 29, 2008 at 10:42:37PM +0900, FUJITA Tomonori wrote: On Mon, 29 Sep 2008 15:26:47 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 10:16:39PM +0900, FUJITA Tomonori wrote: On Sun, 28 Sep 2008 20:49:26 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 11:21:26PM +0900, FUJITA Tomonori wrote: On Mon, 22 Sep 2008 20:21:12 +0200 Joerg Roedel [EMAIL PROTECTED] wrote: Hi, this patch series implements stackable dma_ops on x86. This is useful to be able to fall back to a different dma_ops implementation if one can not handle a particular device (as necessary for example with paravirtualized device passthrough or if a hardware IOMMU only handles a subset of available devices). We already handle the latter. This patchset is more flexible but seems to incur more overheads. This feature will be used for only paravirtualized device passthrough? If so, I feel that there is more simpler (and specific) solutions for it. Its not only for device passthrough. It handles also the cases where a hardware IOMMU does not handle all devices in the system (like in some Calgary systems but also possible with AMD IOMMU). With this patchset we I know that. As I wrote in the previous mail, we already solved that problem with per-device-dma-ops. My question is what unsolved problems this patchset can fix? This patchset is named stackable dma_ops but it's different from what we discussed as stackable dma_ops. This patchset provides IOMMUs a generic mechanism to set up stackable dma_ops. But this patchset doesn't solve the problem that a hardware IOMMU does not handle all devices (it was already solved with per-device-dma-ops). If paravirtualized device passthrough still needs to call multiple dma_ops, then this patchset doesn't solve that issue. Ok, the name stackable is misleading and was a bad choice. I will rename it to multiplexing. This should make it more clear what it is. Like you pointed out, the problems are solved with per-device dma_ops, but in the current implementation it needs special hacks in the IOMMU drivers to use these per-device dma_ops. I see this patchset as a continuation of the per-device dma_ops idea. It moves the per-device handling out of the specific drivers to a common place. So we can avoid or remove special hacks in the IOMMU drivers. Basically, I'm not against this patchset. It simplify Calgary and AMD IOMMUs code to set up per-device-dma-ops (though it makes dma_ops a bit complicated). Yes. But mind that this patchset adds complexity to one point (at dma_ops initialization) while we can avoid and remove it at many other places (in the dma_ops drivers). But it doesn't solve any problems including the paravirtualized device passthrough. When I wrote per-device-dma-ops, I expected that KVM people want more changes (such as stackable dma_ops) to dma_ops for the paravirtualized device passthrough. I'd like to hear what they want first. Sure. Therefore this patchset is RFC and I cc'ed them. 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-76 won't load on x86_64 2.6.24 with openvz
I am attempting to use kvm-76 with a x86_64 2.6.24 kernel from openvz.org The kernel .rpm and src .rpm can be found here: http://wiki.openvz.org/Download/kernel/2.6.24/2.6.24-ovz006.1 kvm-75 works fine with this kernel, but after compiling kvm-76 I get the following error when attempting to modprobe kvm_intel: WARNING: Error inserting kvm (/lib/modules/2.6.24-ovz006.1/extra/kvm.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting kvm_intel (/lib/modules/2.6.24-ovz006.1/extra/kvm-intel.ko): Unknown symbol in module, or unknown parameter (see dmesg) I also see the following in dmesg: kvm: Unknown symbol kvm_iommu_map_pages kvm: Unknown symbol kvm_iommu_map_guest kvm: Unknown symbol kvm_iommu_unmap_guest kvm_intel: Unknown symbol kvm_clear_guest_page kvm_intel: Unknown symbol kvm_exit kvm_intel: Unknown symbol kvm_init kvm_intel: Unknown symbol kvm_enable_efer_bits kvm_intel: Unknown symbol kvm_timer_intr_post kvm_intel: Unknown symbol kvm_mmu_set_nonpresent_ptes kvm_intel: Unknown symbol gfn_to_page kvm_intel: Unknown symbol segment_base kvm_intel: Unknown symbol kvm_get_msr_common kvm_intel: Unknown symbol __kvm_set_memory_region kvm_intel: Unknown symbol kvm_vcpu_uninit kvm_intel: Unknown symbol kvm_emulate_halt kvm_intel: Unknown symbol kvm_set_apic_base kvm_intel: Unknown symbol kvm_report_emulation_failure kvm_intel: Unknown symbol kvm_lapic_find_highest_irr kvm_intel: Unknown symbol kvm_task_switch kvm_intel: Unknown symbol kvm_enable_tdp kvm_intel: Unknown symbol kvm_disable_tdp kvm_intel: Unknown symbol kvm_lmsw kvm_intel: Unknown symbol kvm_set_memory_region kvm_intel: Unknown symbol kvm_queue_exception kvm_intel: Unknown symbol emulate_instruction kvm_intel: Unknown symbol kvm_write_guest_page kvm_intel: Unknown symbol fx_init kvm_intel: Unknown symbol kvm_cpu_has_interrupt kvm_intel: Unknown symbol kvm_lapic_get_cr8 kvm_intel: Unknown symbol kvm_set_cr3 kvm_intel: Unknown symbol kvm_get_cr8 kvm_intel: Unknown symbol kvm_x86_ops kvm_intel: Unknown symbol kvm_vcpu_cache kvm_intel: Unknown symbol kvm_emulate_hypercall kvm_intel: Unknown symbol load_pdptrs kvm_intel: Unknown symbol kvm_handle_fault_on_reboot kvm_intel: Unknown symbol kvm_mmu_unprotect_page_virt kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_mmu_invlpg kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva Here is a link to the .config file used when this kernel was compiled: http://download.openvz.org/kernel/branches/2.6.24/2.6.24-ovz006.1/configs/kernel-2.6.24-x86_64.config.ovz -- 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-76 won't load on x86_64 2.6.24 with openvz
Yeah, comfirmed that you enable CONFIG_DMAR. :) -- regards, Yang, Sheng On Mon, Sep 29, 2008 at 10:07 PM, Sterling Windmill [EMAIL PROTECTED] wrote: I am attempting to use kvm-76 with a x86_64 2.6.24 kernel from openvz.org The kernel .rpm and src .rpm can be found here: http://wiki.openvz.org/Download/kernel/2.6.24/2.6.24-ovz006.1 kvm-75 works fine with this kernel, but after compiling kvm-76 I get the following error when attempting to modprobe kvm_intel: WARNING: Error inserting kvm (/lib/modules/2.6.24-ovz006.1/extra/kvm.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting kvm_intel (/lib/modules/2.6.24-ovz006.1/extra/kvm-intel.ko): Unknown symbol in module, or unknown parameter (see dmesg) I also see the following in dmesg: kvm: Unknown symbol kvm_iommu_map_pages kvm: Unknown symbol kvm_iommu_map_guest kvm: Unknown symbol kvm_iommu_unmap_guest kvm_intel: Unknown symbol kvm_clear_guest_page kvm_intel: Unknown symbol kvm_exit kvm_intel: Unknown symbol kvm_init kvm_intel: Unknown symbol kvm_enable_efer_bits kvm_intel: Unknown symbol kvm_timer_intr_post kvm_intel: Unknown symbol kvm_mmu_set_nonpresent_ptes kvm_intel: Unknown symbol gfn_to_page kvm_intel: Unknown symbol segment_base kvm_intel: Unknown symbol kvm_get_msr_common kvm_intel: Unknown symbol __kvm_set_memory_region kvm_intel: Unknown symbol kvm_vcpu_uninit kvm_intel: Unknown symbol kvm_emulate_halt kvm_intel: Unknown symbol kvm_set_apic_base kvm_intel: Unknown symbol kvm_report_emulation_failure kvm_intel: Unknown symbol kvm_lapic_find_highest_irr kvm_intel: Unknown symbol kvm_task_switch kvm_intel: Unknown symbol kvm_enable_tdp kvm_intel: Unknown symbol kvm_disable_tdp kvm_intel: Unknown symbol kvm_lmsw kvm_intel: Unknown symbol kvm_set_memory_region kvm_intel: Unknown symbol kvm_queue_exception kvm_intel: Unknown symbol emulate_instruction kvm_intel: Unknown symbol kvm_write_guest_page kvm_intel: Unknown symbol fx_init kvm_intel: Unknown symbol kvm_cpu_has_interrupt kvm_intel: Unknown symbol kvm_lapic_get_cr8 kvm_intel: Unknown symbol kvm_set_cr3 kvm_intel: Unknown symbol kvm_get_cr8 kvm_intel: Unknown symbol kvm_x86_ops kvm_intel: Unknown symbol kvm_vcpu_cache kvm_intel: Unknown symbol kvm_emulate_hypercall kvm_intel: Unknown symbol load_pdptrs kvm_intel: Unknown symbol kvm_handle_fault_on_reboot kvm_intel: Unknown symbol kvm_mmu_unprotect_page_virt kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_mmu_invlpg kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva Here is a link to the .config file used when this kernel was compiled: http://download.openvz.org/kernel/branches/2.6.24/2.6.24-ovz006.1/configs/kernel-2.6.24-x86_64.config.ovz -- 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 -- 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-2135061 ] vde support disabled
Bugs item #2135061, was opened at 2008-09-28 21:51 Message generated for change (Comment added) made by aliguori You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2135061group_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: Shen Okinudo (okinu) Assigned to: Nobody/Anonymous (nobody) Summary: vde support disabled Initial Comment: Even when not using the --disable-vde configuratiion flag vde-support shows up with no. Thias happens on an Intel 64 bit host. -- Comment By: Anthony Liguori (aliguori) Date: 2008-09-29 10:42 Message: Do you have the vde development libraries installed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2135061group_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: installing kvm-76 on 2.6.24
Thank you for the information. I apologize for posting twice to the mailing list on the same issue. I was just trying to add some additional information. Could you tell me how to edit the Kbuild file for this purpose? I can also recompile my kernel, but that's a bit more difficult. Thanks in advance, Sterling Windmill - Original Message - From: Sheng Yang [EMAIL PROTECTED] To: Sterling Windmill [EMAIL PROTECTED] Cc: kvm kvm@vger.kernel.org Sent: Monday, September 29, 2008 10:21:10 AM GMT -05:00 US/Canada Eastern Subject: Re: installing kvm-76 on 2.6.24 On Mon, Sep 29, 2008 at 1:09 PM, Sterling Windmill [EMAIL PROTECTED] wrote: I am running a custom compiled 2.6.24 kernel on a 64-bit Intel system and had no issues compling and running kvm-75. I downloaded kvm-76 and compiled and installed it, but I cannot get the modules to load properly. I have temporarily gone back to kvm-75. I am seeing this output in dmesg: kvm: Unknown symbol kvm_iommu_map_pages kvm: Unknown symbol kvm_iommu_map_guest kvm: Unknown symbol kvm_iommu_unmap_guest Seems you enabled CONFIG_DMAR in host kernel side? In theory, we should use CONFIG_DMAR with newly VT-d support in KVM, but the problem now is that userspace including compile option is not ready, so here comes compile problem. If you want to try kvm-76, you may try to disable CONFIG_DMAR in host kernel. Or just wait to userspace VT-d support merge (of course you can add vtd.c manually in Kbuild to overcome this compile issue). :) -- regards, Yang, Sheng -- 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: unhandled vm exit: 0x80000021 vcpu_id 0
On Mon, Sep 29, 2008 at 6:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I have successfully installed windows XP SP2 on kvm. After the installation I have launched the setup of Checkpoint - Pointsec for the entire disk encryption. Hi Pier Can you issue a bug for this? But sadly Checkpoint is a commercial software, we may not deal with it directly and immediately. The first step of installation was run successfully, but when the system reboots and Pointsec loads the initial code, the following error happens: == unhandled vm exit: 0x8021 vcpu_id 0 rax 0007 rbx 1490 rcx rdx 19a0 rsi rdi rsp 0080 rbp 96bf r8 r9 r10 r11 r12 r13 r14 r15 rip 002a rflags 00023202 cs 14a2 (/ p 0 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) ds 19a0 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es 1a31 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 1a29 (/ p 0 dpl 0 db 0 s 0 type 1 l 0 g 0 avl 0) fs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0058 (00201ffa/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 20/1dd8 idt 201df0/188 cr0 8019 cr2 0 cr3 144 cr4 0 cr8 0 efer 0 What's this... CR0.PE clear, CR0.PG set... And segment register also strange. May be some real emulation wrong... Aborted == I am able to boot this system (image) using qemu (with kqemu enabled for user code), but not using kvm. I have also tried with the options: -no-kvm-irqchip -no-kvm-pit -no- acpi without success. Only the -no-kvm option works. I have tried these kvm releases: from 65 to 76; and these kernel (vanilla) releases: from 2.6.23.1 to 2.6.26.5. Thanks for your patient... My computer is a Dell D630 equipped with Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz The HOST Linux distributions used are: Fedora 8/9 for i386, and Fedora 9 for x86_64. Can you show dmesg as well? That's also helps. -- regards, Yang, Sheng -- 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][RESEND] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling
On Mon, 2008-09-29 at 14:50 +0200, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] The 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 that check style, but it is at least less broken than before. Comments and other approaches welcome. This needs to be CCed to [EMAIL PROTECTED] and applied upstream. I don't know if bits/wordsize.h is too Linux-specific (or if that even matters in the configure script). -- 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: installing kvm-76 on 2.6.24
On Mon, Sep 29, 2008 at 10:42 PM, Sterling Windmill [EMAIL PROTECTED] wrote: Thank you for the information. I apologize for posting twice to the mailing list on the same issue. I was just trying to add some additional information. Could you tell me how to edit the Kbuild file for this purpose? I can also recompile my kernel, but that's a bit more difficult. Add vtd.c to kvm-userspace/kernel/x86/Kbuild kvm-objs item should get it done. -- regards, Yang, Sheng Thanks in advance, Sterling Windmill - Original Message - From: Sheng Yang [EMAIL PROTECTED] To: Sterling Windmill [EMAIL PROTECTED] Cc: kvm kvm@vger.kernel.org Sent: Monday, September 29, 2008 10:21:10 AM GMT -05:00 US/Canada Eastern Subject: Re: installing kvm-76 on 2.6.24 On Mon, Sep 29, 2008 at 1:09 PM, Sterling Windmill [EMAIL PROTECTED] wrote: I am running a custom compiled 2.6.24 kernel on a 64-bit Intel system and had no issues compling and running kvm-75. I downloaded kvm-76 and compiled and installed it, but I cannot get the modules to load properly. I have temporarily gone back to kvm-75. I am seeing this output in dmesg: kvm: Unknown symbol kvm_iommu_map_pages kvm: Unknown symbol kvm_iommu_map_guest kvm: Unknown symbol kvm_iommu_unmap_guest Seems you enabled CONFIG_DMAR in host kernel side? In theory, we should use CONFIG_DMAR with newly VT-d support in KVM, but the problem now is that userspace including compile option is not ready, so here comes compile problem. If you want to try kvm-76, you may try to disable CONFIG_DMAR in host kernel. Or just wait to userspace VT-d support merge (of course you can add vtd.c manually in Kbuild to overcome this compile issue). :) -- regards, Yang, Sheng -- 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: installing kvm-76 on 2.6.24
It seems as though I need to insert vtd.o instead of vtd.c My Kbuild file now looks like this: # trick to get the kvm-specific CONFIG_KVM_* definitions, # because the kernel source tree won't have them include $(obj)/../config.kbuild obj-m := kvm.o kvm-intel.o kvm-amd.o kvm-objs := vtd.o kvm_main.o x86.o mmu.o x86_emulate.o ../anon_inodes.o irq.o i8259.o \ lapic.o ioapic.o preempt.o i8254.o coalesced_mmio.o \ ../external-module-compat.o ifeq ($(EXT_CONFIG_KVM_TRACE),y) kvm-objs += kvm_trace.o endif kvm-intel-objs := vmx.o vmx-debug.o ../external-module-compat.o kvm-amd-objs := svm.o ../external-module-compat.o CFLAGS_kvm_main.o = -DKVM_MAIN The modules do compile with this option specified. Unfortunately, the error inserting the modules still persists. Any other ideas? - Original Message - From: Sheng Yang [EMAIL PROTECTED] To: Sterling Windmill [EMAIL PROTECTED] Cc: kvm kvm@vger.kernel.org Sent: Monday, September 29, 2008 10:51:53 AM GMT -05:00 US/Canada Eastern Subject: Re: installing kvm-76 on 2.6.24 On Mon, Sep 29, 2008 at 10:42 PM, Sterling Windmill [EMAIL PROTECTED] wrote: Thank you for the information. I apologize for posting twice to the mailing list on the same issue. I was just trying to add some additional information. Could you tell me how to edit the Kbuild file for this purpose? I can also recompile my kernel, but that's a bit more difficult. Add vtd.c to kvm-userspace/kernel/x86/Kbuild kvm-objs item should get it done. -- regards, Yang, Sheng Thanks in advance, Sterling Windmill - Original Message - From: Sheng Yang [EMAIL PROTECTED] To: Sterling Windmill [EMAIL PROTECTED] Cc: kvm kvm@vger.kernel.org Sent: Monday, September 29, 2008 10:21:10 AM GMT -05:00 US/Canada Eastern Subject: Re: installing kvm-76 on 2.6.24 On Mon, Sep 29, 2008 at 1:09 PM, Sterling Windmill [EMAIL PROTECTED] wrote: I am running a custom compiled 2.6.24 kernel on a 64-bit Intel system and had no issues compling and running kvm-75. I downloaded kvm-76 and compiled and installed it, but I cannot get the modules to load properly. I have temporarily gone back to kvm-75. I am seeing this output in dmesg: kvm: Unknown symbol kvm_iommu_map_pages kvm: Unknown symbol kvm_iommu_map_guest kvm: Unknown symbol kvm_iommu_unmap_guest Seems you enabled CONFIG_DMAR in host kernel side? In theory, we should use CONFIG_DMAR with newly VT-d support in KVM, but the problem now is that userspace including compile option is not ready, so here comes compile problem. If you want to try kvm-76, you may try to disable CONFIG_DMAR in host kernel. Or just wait to userspace VT-d support merge (of course you can add vtd.c manually in Kbuild to overcome this compile issue). :) -- regards, Yang, Sheng -- 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] fold struct vcpu_info into CPUState
Hi,
Trying to get rid of the static declaration of the vcpu_info array, this
patch folds it into CPUState. I have only been able to test it on ia64,
but it seems to behave as expect, however ia64 SMP support is still a
bit flakey, so I would appreciate it if someone would test this on x86
and PPC. It builds on x86_64 at least.
Comments appreciated.
Thanks,
Jes
Merge vcpu_info into CPUState.
Moves definition of vcpu related structs to new header qemu-kvm-vcpu.h
and declares this struct in i386/ia64/ppc CPUState structs if USE_KVM
is defined. In addition conver qemu-kvm.c to pull vcpu_info out of
CPUState.
This eliminates ugly static sized array of struct vcpu_info.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
---
qemu/qemu-kvm-vcpu.h | 34 +++
qemu/qemu-kvm.c| 141 ++---
qemu/target-i386/cpu.h |4 +
qemu/target-ia64/cpu.h |5 +
qemu/target-ppc/cpu.h |5 +
5 files changed, 125 insertions(+), 64 deletions(-)
Index: kvm-userspace.git/qemu/qemu-kvm-vcpu.h
===
--- /dev/null
+++ kvm-userspace.git/qemu/qemu-kvm-vcpu.h
@@ -0,0 +1,34 @@
+/*
+ * qemu/kvm vcpu definitions
+ *
+ * Copyright (C) 2006-2008 Qumranet Technologies
+ *
+ * Licensed under the terms of the GNU GPL version 2 or higher.
+ */
+#ifndef QEMU_KVM_VCPU_H
+#define QEMU_KVM_VCPU_H
+
+#include pthread.h
+
+struct qemu_kvm_work_item {
+struct qemu_kvm_work_item *next;
+void (*func)(void *data);
+void *data;
+int done;
+};
+
+/*
+ * KVM vcpu struct
+ */
+struct vcpu_info {
+int sipi_needed;
+int init;
+pthread_t thread;
+int signalled;
+int stop;
+int stopped;
+int created;
+struct qemu_kvm_work_item *queued_work_first, *queued_work_last;
+};
+
+#endif
Index: kvm-userspace.git/qemu/qemu-kvm.c
===
--- kvm-userspace.git.orig/qemu/qemu-kvm.c
+++ kvm-userspace.git/qemu/qemu-kvm.c
@@ -22,13 +22,13 @@
#include compatfd.h
#include qemu-kvm.h
+#include qemu-kvm-vcpu.h
#include libkvm.h
#include pthread.h
#include sys/utsname.h
#include sys/syscall.h
#include sys/mman.h
-#define bool _Bool
#define false 0
#define true 1
@@ -43,31 +43,12 @@
pthread_cond_t qemu_system_cond = PTHREAD_COND_INITIALIZER;
pthread_cond_t qemu_pause_cond = PTHREAD_COND_INITIALIZER;
pthread_cond_t qemu_work_cond = PTHREAD_COND_INITIALIZER;
-__thread struct vcpu_info *vcpu;
+__thread struct CPUState *current_env;
static int qemu_system_ready;
#define SIG_IPI (SIGRTMIN+4)
-struct qemu_kvm_work_item {
-struct qemu_kvm_work_item *next;
-void (*func)(void *data);
-void *data;
-bool done;
-};
-
-struct vcpu_info {
-CPUState *env;
-int sipi_needed;
-int init;
-pthread_t thread;
-int signalled;
-int stop;
-int stopped;
-int created;
-struct qemu_kvm_work_item *queued_work_first, *queued_work_last;
-} vcpu_info[256];
-
pthread_t io_thread;
static int io_thread_fd = -1;
static int io_thread_sigfd = -1;
@@ -93,7 +74,20 @@
CPUState *qemu_kvm_cpu_env(int index)
{
-return vcpu_info[index].env;
+CPUState *penv;
+
+if (current_env-cpu_index == index)
+return current_env;
+
+penv = first_cpu;
+
+while (penv) {
+if (penv-cpu_index == index)
+return penv;
+penv = (CPUState *)penv-next_cpu;
+}
+
+return NULL;
}
static void sig_ipi_handler(int n)
@@ -102,10 +96,10 @@
static void on_vcpu(CPUState *env, void (*func)(void *data), void *data)
{
-struct vcpu_info *vi = vcpu_info[env-cpu_index];
+struct vcpu_info *vi = env-vcpu_info;
struct qemu_kvm_work_item wi;
-if (vi == vcpu) {
+if (env == current_env) {
func(data);
return;
}
@@ -130,29 +124,33 @@
int signal = 0;
if (env) {
-if (!vcpu)
+if (!current_env-vcpu_info.created)
signal = 1;
-if (vcpu env != vcpu-env !vcpu_info[env-cpu_index].signalled)
+/*
+ * Testing for vcpu_info.created here is really redundant
+ */
+if (current_env-vcpu_info.created
+env != current_env env-vcpu_info.signalled)
signal = 1;
if (signal) {
-vcpu_info[env-cpu_index].signalled = 1;
-if (vcpu_info[env-cpu_index].thread)
-pthread_kill(vcpu_info[env-cpu_index].thread, SIG_IPI);
+env-vcpu_info.signalled = 1;
+if (env-vcpu_info.thread)
+pthread_kill(env-vcpu_info.thread, SIG_IPI);
}
}
}
void kvm_update_after_sipi(CPUState *env)
{
-vcpu_info[env-cpu_index].sipi_needed = 1;
+env-vcpu_info.sipi_needed = 1;
kvm_update_interrupt_request(env);
}
void kvm_apic_init(CPUState *env)
{
if (env-cpu_index != 0)
- vcpu_info[env-cpu_index].init = 1;
+ env-vcpu_info.init = 1;
Re: installing kvm-76 on 2.6.24
On Mon, Sep 29, 2008 at 11:18 PM, Sterling Windmill [EMAIL PROTECTED] wrote: It seems as though I need to insert vtd.o instead of vtd.c Yeah... That's vtd.o :) And I forgot, if you want to compile vtd.c, you need compile kvm kernel space rather than other kernel version for we modified host kernel side. Sorry for I don't have a box by hand so that I can't check every detail... I suppose you want to keep your kernel? Maybe disable CONFIG_DMAR is more easy... -- regards, Yang, Sheng My Kbuild file now looks like this: # trick to get the kvm-specific CONFIG_KVM_* definitions, # because the kernel source tree won't have them include $(obj)/../config.kbuild obj-m := kvm.o kvm-intel.o kvm-amd.o kvm-objs := vtd.o kvm_main.o x86.o mmu.o x86_emulate.o ../anon_inodes.o irq.o i8259.o \ lapic.o ioapic.o preempt.o i8254.o coalesced_mmio.o \ ../external-module-compat.o ifeq ($(EXT_CONFIG_KVM_TRACE),y) kvm-objs += kvm_trace.o endif kvm-intel-objs := vmx.o vmx-debug.o ../external-module-compat.o kvm-amd-objs := svm.o ../external-module-compat.o CFLAGS_kvm_main.o = -DKVM_MAIN The modules do compile with this option specified. Unfortunately, the error inserting the modules still persists. Any other ideas? - Original Message - From: Sheng Yang [EMAIL PROTECTED] To: Sterling Windmill [EMAIL PROTECTED] Cc: kvm kvm@vger.kernel.org Sent: Monday, September 29, 2008 10:51:53 AM GMT -05:00 US/Canada Eastern Subject: Re: installing kvm-76 on 2.6.24 On Mon, Sep 29, 2008 at 10:42 PM, Sterling Windmill [EMAIL PROTECTED] wrote: Thank you for the information. I apologize for posting twice to the mailing list on the same issue. I was just trying to add some additional information. Could you tell me how to edit the Kbuild file for this purpose? I can also recompile my kernel, but that's a bit more difficult. Add vtd.c to kvm-userspace/kernel/x86/Kbuild kvm-objs item should get it done. -- regards, Yang, Sheng Thanks in advance, Sterling Windmill - Original Message - From: Sheng Yang [EMAIL PROTECTED] To: Sterling Windmill [EMAIL PROTECTED] Cc: kvm kvm@vger.kernel.org Sent: Monday, September 29, 2008 10:21:10 AM GMT -05:00 US/Canada Eastern Subject: Re: installing kvm-76 on 2.6.24 On Mon, Sep 29, 2008 at 1:09 PM, Sterling Windmill [EMAIL PROTECTED] wrote: I am running a custom compiled 2.6.24 kernel on a 64-bit Intel system and had no issues compling and running kvm-75. I downloaded kvm-76 and compiled and installed it, but I cannot get the modules to load properly. I have temporarily gone back to kvm-75. I am seeing this output in dmesg: kvm: Unknown symbol kvm_iommu_map_pages kvm: Unknown symbol kvm_iommu_map_guest kvm: Unknown symbol kvm_iommu_unmap_guest Seems you enabled CONFIG_DMAR in host kernel side? In theory, we should use CONFIG_DMAR with newly VT-d support in KVM, but the problem now is that userspace including compile option is not ready, so here comes compile problem. If you want to try kvm-76, you may try to disable CONFIG_DMAR in host kernel. Or just wait to userspace VT-d support merge (of course you can add vtd.c manually in Kbuild to overcome this compile issue). :) -- regards, Yang, Sheng -- 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: installing kvm-76 on 2.6.24
* On Monday 29 Sep 2008 20:59:56 Sheng Yang wrote: On Mon, Sep 29, 2008 at 11:18 PM, Sterling Windmill [EMAIL PROTECTED] wrote: It seems as though I need to insert vtd.o instead of vtd.c Yeah... That's vtd.o :) And I forgot, if you want to compile vtd.c, you need compile kvm kernel space rather than other kernel version for we modified host kernel side. Sorry for I don't have a box by hand so that I can't check every detail... I suppose you want to keep your kernel? Maybe disable CONFIG_DMAR is more easy... But that's just three messages of the several undefined symbols he's getting. -- 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-76 --std-vga problem
On Sun, Sep 28, 2008 at 6:44 PM, Michael Malone [EMAIL PROTECTED] wrote: 2) (this has been around for quite some time, I just haven't done anything about it) Even though I start up with -smp 2, windows only reads 1 cpu 3) When I run it using the --std-vga parameter, windows boots to just before it gets to the welcome screen and hangs. The output shows a multitude of kvm: get_dirty_pages returned -2 Is this something to do with the kernel version I am using? I am using the standard Ubuntu Hardy Kernel No. It's a regression introduced in last version. It should work using cirrus vga (can you confirm, please?) It happens because for the specific range std vga is relying the memory will be, it do a cpu_register_physical_mem(). When kvm tries to create a new piece of memory in this place, it's marked as already existant. There are some quick hacks, but I'll be trying to work on a proper fix in the following days. -- 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: kvm-76 --std-vga problem
On Mon, Sep 29, 2008 at 2:29 PM, Glauber Costa [EMAIL PROTECTED] wrote:
On Sun, Sep 28, 2008 at 6:44 PM, Michael Malone
[EMAIL PROTECTED] wrote:
2) (this has been around for quite some time, I just haven't done anything
about it)
Even though I start up with -smp 2, windows only reads 1 cpu
3) When I run it using the --std-vga parameter, windows boots to just before
it gets to the welcome screen and hangs. The output shows a multitude of
kvm: get_dirty_pages returned -2 Is this something to do with the kernel
version I am using? I am using the standard Ubuntu Hardy Kernel
No. It's a regression introduced in last version. It should work using
cirrus vga (can you confirm, please?)
It happens because for the specific range std vga is relying the
memory will be, it do a cpu_register_physical_mem().
When kvm tries to create a new piece of memory in this place, it's
marked as already existant.
There are some quick hacks, but I'll be trying to work on a proper fix
in the following days.
This is a band aid, but proves the general idea. Can you confirm that
it fixes the problem for you ?
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index dfa63bb..6abb3b9 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -399,8 +399,7 @@ int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
return 0;
}
-
-void *kvm_create_phys_mem(kvm_context_t kvm, unsigned long phys_start,
+void *kvm_set_phys_mem(kvm_context_t kvm, unsigned long phys_start,
unsigned long len, int log, int writable)
{
int r;
@@ -441,6 +440,23 @@ void *kvm_create_phys_mem(kvm_context_t kvm, unsigned long phys_start,
return ptr;
}
+void *kvm_create_phys_mem(kvm_context_t kvm, unsigned long phys_start,
+ unsigned long len, int log, int writable)
+{
+ int slot = get_container_slot(phys_start, len);
+ int flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0;
+
+ if (slot == -1) {
+ return kvm_set_phys_mem(kvm, phys_start, len, log, writable);
+ }
+ if (slots[slot].flags == flags) {
+ return slots[slot].userspace_addr;
+ } else {
+ kvm_destroy_phys_mem(kvm, phys_start, len);
+ return kvm_set_phys_mem(kvm, phys_start, len, log, writable);
+ }
+}
+
int kvm_register_phys_mem(kvm_context_t kvm,
unsigned long phys_start, void *userspace_addr,
unsigned long len, int log)
Re: [PATCH] Make KVM compile on split source/object kernel configurations
Any further comments on this? I would really like to see KVM build out-
of-the-box on SUSE kernels (and kernels built with O= at the same time).
Alex
On 15.09.2008, at 16:19, Alexander Graf wrote:
KVM as is assumes that the kernel obj dir and the kernel source dir
are at the same location. This is true for most self-built vanilla
kernels, but some distributions split these up (e.g. SUSE).
To keep compatible and have users have a good experience on building
KVM on any distribution, this patch attempts to rebuild the logic
from the kernel Makefile as closely as possible. With it I
successfully built KVM on a current SUSE system.
Signed-off-by: Alexander Graf [EMAIL PROTECTED]
Please check and see if it breaks the build process for anyone else.
Building with IA64 on SUSE-kernels is still broken due to similar
but separate problems.
diff --git a/configure b/configure
index 3bb10ce..5e9cbab 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,7 @@
#!/bin/bash
prefix=/usr/local
+kernelsourcedir=
kerneldir=/lib/modules/$(uname -r)/build
cc=gcc
ld=ld
@@ -102,6 +103,11 @@ if [ $arch = powerpc ]; then
qemu_ldflags=$qemu_ldflags -L $PWD/libfdt
fi
+# see if we have split build and source directories
+if [ -d $kerneldir/include2 ]; then
+kernelsourcedir=${kerneldir%/*}/source
+fi
+
#configure user dir
(cd user; ./configure --prefix=$prefix --
kerneldir=$libkvm_kerneldir \
--arch=$arch \
@@ -124,6 +130,7 @@ cat EOF config.mak
ARCH=$arch
PREFIX=$prefix
KERNELDIR=$kerneldir
+KERNELSOURCEDIR=$kernelsourcedir
LIBKVM_KERNELDIR=$libkvm_kerneldir
WANT_MODULE=$want_module
CROSS_COMPILE=$cross_prefix
diff --git a/kernel/Makefile b/kernel/Makefile
index 3f5f6da..d2cf89c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -36,7 +36,9 @@ hack-files = $(hack-files-$(ARCH_DIR))
all:: header-link prerequisite
# include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
$(MAKE) -C $(KERNELDIR) M=`pwd` \
- LINUXINCLUDE=-I`pwd`/include -Iinclude -Iarch/${ARCH_DIR}/
include -I`pwd`/include-compat \
+ LINUXINCLUDE=-I`pwd`/include -Iinclude \
+ $(if $(KERNELSOURCEDIR),-Iinclude2
-I$(KERNELSOURCEDIR)/include) \
+ -Iarch/${ARCH_DIR}/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/$(ARCH_DIR)/external-module-compat.h
$$@
--
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] Make KVM compile on split source/object kernel configurations
Alexander Graf wrote:
Any further comments on this? I would really like to see KVM build
out-of-the-box on SUSE kernels (and kernels built with O= at the same
time).
Alex
/me, too. And my colleagues @work. We carry around an old hack to build
against SuSE, now waiting for your clean solution to be merged.
Jan
On 15.09.2008, at 16:19, Alexander Graf wrote:
KVM as is assumes that the kernel obj dir and the kernel source dir
are at the same location. This is true for most self-built vanilla
kernels, but some distributions split these up (e.g. SUSE).
To keep compatible and have users have a good experience on building
KVM on any distribution, this patch attempts to rebuild the logic from
the kernel Makefile as closely as possible. With it I successfully
built KVM on a current SUSE system.
Signed-off-by: Alexander Graf [EMAIL PROTECTED]
Please check and see if it breaks the build process for anyone else.
Building with IA64 on SUSE-kernels is still broken due to similar but
separate problems.
diff --git a/configure b/configure
index 3bb10ce..5e9cbab 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,7 @@
#!/bin/bash
prefix=/usr/local
+kernelsourcedir=
kerneldir=/lib/modules/$(uname -r)/build
cc=gcc
ld=ld
@@ -102,6 +103,11 @@ if [ $arch = powerpc ]; then
qemu_ldflags=$qemu_ldflags -L $PWD/libfdt
fi
+# see if we have split build and source directories
+if [ -d $kerneldir/include2 ]; then
+kernelsourcedir=${kerneldir%/*}/source
+fi
+
#configure user dir
(cd user; ./configure --prefix=$prefix
--kerneldir=$libkvm_kerneldir \
--arch=$arch \
@@ -124,6 +130,7 @@ cat EOF config.mak
ARCH=$arch
PREFIX=$prefix
KERNELDIR=$kerneldir
+KERNELSOURCEDIR=$kernelsourcedir
LIBKVM_KERNELDIR=$libkvm_kerneldir
WANT_MODULE=$want_module
CROSS_COMPILE=$cross_prefix
diff --git a/kernel/Makefile b/kernel/Makefile
index 3f5f6da..d2cf89c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -36,7 +36,9 @@ hack-files = $(hack-files-$(ARCH_DIR))
all:: header-link prerequisite
#include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
$(MAKE) -C $(KERNELDIR) M=`pwd` \
-LINUXINCLUDE=-I`pwd`/include -Iinclude
-Iarch/${ARCH_DIR}/include -I`pwd`/include-compat \
+LINUXINCLUDE=-I`pwd`/include -Iinclude \
+$(if $(KERNELSOURCEDIR),-Iinclude2
-I$(KERNELSOURCEDIR)/include) \
+-Iarch/${ARCH_DIR}/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/$(ARCH_DIR)/external-module-compat.h
$$@
--
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
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Make KVM compile on split source/object kernel configurations
With your patch, I still can't build with a split kernel source/object dir.
Don't know if it's a difference of configure options or what. Here's mine just
in case:
./configure --disable-gfx-check --disable-sdl --with-patched-kernel
--prefix=/usr
I needed the attached patch as well.
On Monday 29 September 2008 1:13:52 pm Alexander Graf wrote:
Any further comments on this? I would really like to see KVM build out-
of-the-box on SUSE kernels (and kernels built with O= at the same time).
Alex
On 15.09.2008, at 16:19, Alexander Graf wrote:
KVM as is assumes that the kernel obj dir and the kernel source dir
are at the same location. This is true for most self-built vanilla
kernels, but some distributions split these up (e.g. SUSE).
To keep compatible and have users have a good experience on building
KVM on any distribution, this patch attempts to rebuild the logic
from the kernel Makefile as closely as possible. With it I
successfully built KVM on a current SUSE system.
Signed-off-by: Alexander Graf [EMAIL PROTECTED]
Please check and see if it breaks the build process for anyone else.
Building with IA64 on SUSE-kernels is still broken due to similar
but separate problems.
diff --git a/configure b/configure
index 3bb10ce..5e9cbab 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,7 @@
#!/bin/bash
prefix=/usr/local
+kernelsourcedir=
kerneldir=/lib/modules/$(uname -r)/build
cc=gcc
ld=ld
@@ -102,6 +103,11 @@ if [ $arch = powerpc ]; then
qemu_ldflags=$qemu_ldflags -L $PWD/libfdt
fi
+# see if we have split build and source directories
+if [ -d $kerneldir/include2 ]; then
+kernelsourcedir=${kerneldir%/*}/source
+fi
+
#configure user dir
(cd user; ./configure --prefix=$prefix --
kerneldir=$libkvm_kerneldir \
--arch=$arch \
@@ -124,6 +130,7 @@ cat EOF config.mak
ARCH=$arch
PREFIX=$prefix
KERNELDIR=$kerneldir
+KERNELSOURCEDIR=$kernelsourcedir
LIBKVM_KERNELDIR=$libkvm_kerneldir
WANT_MODULE=$want_module
CROSS_COMPILE=$cross_prefix
diff --git a/kernel/Makefile b/kernel/Makefile
index 3f5f6da..d2cf89c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -36,7 +36,9 @@ hack-files = $(hack-files-$(ARCH_DIR))
all:: header-link prerequisite
# include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
$(MAKE) -C $(KERNELDIR) M=`pwd` \
- LINUXINCLUDE=-I`pwd`/include -Iinclude -Iarch/${ARCH_DIR}/
include -I`pwd`/include-compat \
+ LINUXINCLUDE=-I`pwd`/include -Iinclude \
+ $(if $(KERNELSOURCEDIR),-Iinclude2
-I$(KERNELSOURCEDIR)/include) \
+ -Iarch/${ARCH_DIR}/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/$(ARCH_DIR)/external-module-compat.h
$$@
--
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
diff --git a/kernel/Makefile b/kernel/Makefile
index f2a71fa..46948cc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -58,8 +58,8 @@ T = $(subst -sync,,$@)-tmp
header-sync:
rm -rf $T
rsync -R \
- $(LINUX)/./include/linux/kvm*.h \
- $(LINUX)/./include/asm-*/kvm*.h \
+ $(subst build,source,$(LINUX))/./include/linux/kvm*.h \
+ $(subst build,source,$(LINUX))/./include/asm-*/kvm*.h \
$T/
-rsync -R \
$(LINUX)/arch/$(ARCH_DIR)/include/asm/./kvm*.h \
Re: [PATCH] Make KVM compile on split source/object kernel configurations
On 29.09.2008, at 23:50, Brian Jackson wrote: With your patch, I still can't build with a split kernel source/ object dir. Don't know if it's a difference of configure options or what. Here's mine just in case: ./configure --disable-gfx-check --disable-sdl --with-patched-kernel --prefix=/usr I needed the attached patch as well. Does --with-patched-kernel work again? I thought that's broken anyways. Alex -- 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 of 7] kvm: ppc: Rename struct tlbe to struct kvmppc_44x_tlbe
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1222627837 18000
# Node ID e954cb04a648e694f35e2baaa43f430ebc6b65ca
# Parent 545c3dea0b56ba996a8fcd48bdae903092319a27
kvm: ppc: Rename struct tlbe to struct kvmppc_44x_tlbe
This will ease ports to other cores.
Also remove unused struct kvm_tlb while we're at it.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -64,7 +64,7 @@ struct kvm_vcpu_stat {
u32 halt_wakeup;
};
-struct tlbe {
+struct kvmppc_44x_tlbe {
u32 tid; /* Only the low 8 bits are used. */
u32 word0;
u32 word1;
@@ -76,9 +76,9 @@ struct kvm_arch {
struct kvm_vcpu_arch {
/* Unmodified copy of the guest's TLB. */
- struct tlbe guest_tlb[PPC44x_TLB_SIZE];
+ struct kvmppc_44x_tlbe guest_tlb[PPC44x_TLB_SIZE];
/* TLB that's actually used when the guest is running. */
- struct tlbe shadow_tlb[PPC44x_TLB_SIZE];
+ struct kvmppc_44x_tlbe shadow_tlb[PPC44x_TLB_SIZE];
/* Pages which are referenced in the shadow TLB. */
struct page *shadow_pages[PPC44x_TLB_SIZE];
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -28,11 +28,6 @@
#include linux/types.h
#include linux/kvm_types.h
#include linux/kvm_host.h
-
-struct kvm_tlb {
- struct tlbe guest_tlb[PPC44x_TLB_SIZE];
- struct tlbe shadow_tlb[PPC44x_TLB_SIZE];
-};
enum emulation_result {
EMULATE_DONE, /* no further processing */
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -352,7 +352,7 @@ int main(void)
DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE);
#ifdef CONFIG_KVM
- DEFINE(TLBE_BYTES, sizeof(struct tlbe));
+ DEFINE(TLBE_BYTES, sizeof(struct kvmppc_44x_tlbe));
DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, arch.host_stack));
DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid));
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -86,7 +86,7 @@ int kvmppc_44x_tlb_index(struct kvm_vcpu
/* XXX Replace loop with fancy data structures. */
for (i = 0; i PPC44x_TLB_SIZE; i++) {
- struct tlbe *tlbe = vcpu-arch.guest_tlb[i];
+ struct kvmppc_44x_tlbe *tlbe = vcpu-arch.guest_tlb[i];
unsigned int tid;
if (eaddr get_tlb_eaddr(tlbe))
@@ -111,7 +111,8 @@ int kvmppc_44x_tlb_index(struct kvm_vcpu
return -1;
}
-struct tlbe *kvmppc_44x_itlb_search(struct kvm_vcpu *vcpu, gva_t eaddr)
+struct kvmppc_44x_tlbe *kvmppc_44x_itlb_search(struct kvm_vcpu *vcpu,
+ gva_t eaddr)
{
unsigned int as = !!(vcpu-arch.msr MSR_IS);
unsigned int index;
@@ -122,7 +123,8 @@ struct tlbe *kvmppc_44x_itlb_search(stru
return vcpu-arch.guest_tlb[index];
}
-struct tlbe *kvmppc_44x_dtlb_search(struct kvm_vcpu *vcpu, gva_t eaddr)
+struct kvmppc_44x_tlbe *kvmppc_44x_dtlb_search(struct kvm_vcpu *vcpu,
+ gva_t eaddr)
{
unsigned int as = !!(vcpu-arch.msr MSR_DS);
unsigned int index;
@@ -133,7 +135,7 @@ struct tlbe *kvmppc_44x_dtlb_search(stru
return vcpu-arch.guest_tlb[index];
}
-static int kvmppc_44x_tlbe_is_writable(struct tlbe *tlbe)
+static int kvmppc_44x_tlbe_is_writable(struct kvmppc_44x_tlbe *tlbe)
{
return tlbe-word2 (PPC44x_TLB_SW|PPC44x_TLB_UW);
}
@@ -142,7 +144,7 @@ static void kvmppc_44x_shadow_release(st
static void kvmppc_44x_shadow_release(struct kvm_vcpu *vcpu,
unsigned int index)
{
- struct tlbe *stlbe = vcpu-arch.shadow_tlb[index];
+ struct kvmppc_44x_tlbe *stlbe = vcpu-arch.shadow_tlb[index];
struct page *page = vcpu-arch.shadow_pages[index];
if (get_tlb_v(stlbe)) {
@@ -164,7 +166,7 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
u32 flags)
{
struct page *new_page;
- struct tlbe *stlbe;
+ struct kvmppc_44x_tlbe *stlbe;
hpa_t hpaddr;
unsigned int victim;
@@ -224,7 +226,7 @@ static void kvmppc_mmu_invalidate(struct
/* XXX Replace loop with fancy data structures. */
down_write(current-mm-mmap_sem);
for (i = 0; i = tlb_44x_hwater; i++) {
- struct tlbe *stlbe = vcpu-arch.shadow_tlb[i];
+ struct kvmppc_44x_tlbe *stlbe = vcpu-arch.shadow_tlb[i];
unsigned int tid;
if (!get_tlb_v(stlbe))
@@ -261,7 +263,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
