Re: [Qemu-devel] 8139cp problems - steps to reproduce
Hi, did You try both noapic nolapic? this helped me... n. On Fri, Sep 12, 2008 at 11:37:33PM +0200, xming wrote: hi, I am running kvm-74 and it's getting worse for me (compared to 73, or 70,71 w/o issues), I tried virtio, rtl8139 and e1000, the network will stall. With 8139 it happens very quick (few MB via nfs) and I noticed that I can bring up the network by setting the stalled NIC (in the guest) by setting it to promisc and -promisc repeatably. I can now perfectly reproduced the stall and un-stall. When it's stalled I noticed on the host that the nic is not totally gone, arp broadcast still gets out. Any ideas? -- - Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: [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: [Qemu-devel] 8139cp problems - steps to reproduce
Hi David, well, I tried e1000, but it's actualy much worse for me. But I'm using much newer (vanilla) kernels, maybe RHEL kernels contain some patch that prevents the problem? I'll have a look. BR nik On Mon, Sep 15, 2008 at 09:45:56AM -0600, David S. Ahern wrote: Last February I dug into where it was getting stuck. See: http://article.gmane.org/gmane.comp.emulators.kvm.devel/13537/match=pci%5fset%5firq and follow up posts. For the past 5-6 months I've been using the e1000 nic in rhel3 and rhel4 guests without a problem -- and without the need for guest hacks like noapic. david xming wrote: hi, I am running kvm-74 and it's getting worse for me (compared to 73, or 70,71 w/o issues), I tried virtio, rtl8139 and e1000, the network will stall. With 8139 it happens very quick (few MB via nfs) and I noticed that I can bring up the network by setting the stalled NIC (in the guest) by setting it to promisc and -promisc repeatably. I can now perfectly reproduced the stall and un-stall. When it's stalled I noticed on the host that the nic is not totally gone, arp broadcast still gets out. Any ideas? -- 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 -- - Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: [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: [PATCH] Make KVM compile on split source/object kernel configurations
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. Hi, Graf what problems did you meet when building kvm/ia64 ? Xiantao -- 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-2113643 ] guests AND host still getting stuck under CPU load
Bugs item #2113643, was opened at 2008-09-16 09:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2113643group_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: Nikola Ciprich (nikola_ciprich) Assigned to: Nobody/Anonymous (nobody) Summary: guests AND host still getting stuck under CPU load Initial Comment: I'm experiencing problems with some KVM guests getting stuck for long time when all their CPUs are loaded. Host: 8xCPU intel, 2.6.26 x86_64, kvm-74, 12GB RAM Guest: 8XCPU, 2.6.24 x86_64 1GB RAM while doing kernel compilation on guest (using -j8), the guest sometimes hangs for long time, and on host I see: Sep 12 19:04:34 vbox1 [420515.344071] BUG: soft lockup - CPU#3 stuck for 99s! [qemu-system-x86:17351] Sep 12 19:04:34 vbox1 [420515.344071] Modules linked in: tun bitrev drbd lock_dlm gfs2 cn crc32 dlm configfs ipmi_si ipmi_devintf ipmi_m sghandler ipt_REJECT xt_tcpudp xt_multiport nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables kvm_intel kvm ipv6 nfs lockd nfs_acl sunrpc 8021q bridge llc dm_mirror dm_log dm_mod wmi sbs sbshc fan battery backlight acpi_memhotplug ac lp nvram e1000 e sg snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss piix snd_pcm container pata_acpi ide_ pci_generic snd_timer snd soundcore snd_page_alloc parport_pc parport thermal processor ata_piix ata_generic button rng_core thermal_sys iTCO_wdt rtc_cmos rtc_core rtc_lib i5000_edac shpchp i2c_i801 i2c_core pci_hotplug edac_core pcspkr ide_disk ide_core aic94xx libsas fi rmware_class scsi_transport_sas ahci libata dock sd_mod scsi_mod raid456 async_xor async_memcpy async_tx xor raid1 ext3 jbd uhci_hcd ohc i_hcd ehci_hcd [last unloaded: scsi_wait_scan] Sep 12 19:04:34 vbox1 [420515.344071] CPU 3: Sep 12 19:04:34 vbox1 [420515.344071] Pid: 17351, comm: qemu-system-x86 Not tainted 2.6.26lb.02 #1 Sep 12 19:04:34 vbox1 [420515.344071] RIP: 0010:[803e8cc1] [803e8cc1] sock_poll+0x11/0x20 Sep 12 19:04:34 vbox1 [420515.344071] RSP: 0018:8100bd355a50 EFLAGS: 0246 Sep 12 19:04:34 vbox1 [420515.344071] RAX: RBX: 0080 RCX: 804c3520 Sep 12 19:04:34 vbox1 [420515.344071] RDX: RSI: 8102632fe140 RDI: 8101b4c8bbc0 Sep 12 19:04:34 vbox1 [420515.344071] RBP: 810217faa800 R08: 0001 R09: 8029e9df Sep 12 19:04:34 vbox1 [420515.344071] R10: R11: R12: 8023e743 Sep 12 19:04:34 vbox1 [420515.344071] R13: 0001 R14: 8100bd355a08 R15: Sep 12 19:04:34 vbox1 [420515.344071] FS: 7f47f0a5e6f0() GS:81032fce65c0() knlGS: Sep 12 19:04:34 vbox1 [420515.344071] CS: 0010 DS: ES: CR0: 8005003b Sep 12 19:04:34 vbox1 [420515.344071] CR2: b7f43000 CR3: c01d6000 CR4: 26e0 Sep 12 19:04:34 vbox1 [420515.344071] DR0: DR1: DR2: Sep 12 19:04:34 vbox1 [420515.344071] DR3: DR6: 0ff0 DR7: 0400 Sep 12 19:04:34 vbox1 [420515.344071] Sep 12 19:04:34 vbox1 [420515.344071] Call Trace: Sep 12 19:04:34 vbox1 [420515.344071] [802ac800] ? do_select+0x330/0x590 Sep 12 19:04:34 vbox1 [420515.344071] [802ad040] ? __pollwait+0x0/0x130 Sep 12 19:04:34 vbox1 [420515.344071] [8022a440] ? default_wake_function+0x0/0x10 Sep 12 19:04:34 vbox1 [420515.344071] [8022a440] ? default_wake_function+0x0/0x10 Sep 12 19:04:34 vbox1 [420515.344071] [8022a440] ? default_wake_function+0x0/0x10 Sep 12 19:04:34 vbox1 [420515.344071] [8022a440] ? default_wake_function+0x0/0x10 Sep 12 19:04:34 vbox1 [420515.344071] [8022a440] ? default_wake_function+0x0/0x10 Sep 12 19:04:34 vbox1 [420515.344071] [8022a440] ? default_wake_function+0x0/0x10 Sep 12 19:04:34 vbox1 [420515.344071] [80249d99] ? autoremove_wake_function+0x9/0x30 Sep 12 19:04:34 vbox1 [420515.344071] [80227cca] ? __wake_up_common+0x5a/0x90 Sep 12 19:04:34 vbox1 [420515.344071] [80480a07] ? _spin_lock_irqsave+0x37/0x50 Sep 12 19:04:34 vbox1 [420515.344071] [a05624dd] ? :tun:tun_chr_aio_read+0x12d/0x3b0 Sep 12 19:04:34 vbox1 [420515.344071] [802acca9] ? core_sys_select+0x249/0x340 Sep 12 19:04:34 vbox1 [420515.344071] [80249d90] ? autoremove_wake_function+0x0/0x30 Sep 12 19:04:34 vbox1 [420515.344071] [a03e7c6e] ? :kvm:kvm_vm_ioctl+0x8e/0x270 Sep 12 19:04:34 vbox1 [420515.344071] [80316229] ? file_has_perm+0xe9/0xf0 Sep 12
stability issue with KVM using SMP
Summary - I'm getting stability issues running SMP. The guest will run for, typically, 6 to 12 hours before causing a problem. The first time it happened the guest process that was running SMP went Zombie, but in a spin loop clocking huge amount of CPU time, and I had to reboot the host to clear it. Needless to say I had no access to the guest's qmeu console (Ctrl-Alt-2) and a kill -9 pid from the host had no effect. However, the kernel had been compiled with a 64Gb memory model and I've had problems with that in the past - in fact that's the first time I've seen a kernel compiled with the 64Gb memory model actually boot under KVM. So I replaced the kernel and the next time the guest simply locked up - I couldn't access the guest o/s at all (no ping, no linux console response etc - in some cases there was a picture on the console [login prompt] but it didn't respond to any key presses), but the qemu console still worked. I tried a system_powerdown and that failed so I did a system_reset and that rebooted the client. I have now switched off SMP and the guest is working fine (just SLOW). I've had quite a few non-SMP linux guests running on this host for some time, using various kernels, and not seen a problem. Its only since I tried to introduce SMP that its all gone pear shaped. # what cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210). See /proc/cpuinfo if you're not sure. dual Quad-Core AMD Opteron(tm) Processor 2352 with 32Gb RAM # what kvm version you are using. If you're using git directly, provide the output of 'git describe'. kvm-72 # the host kernel version 2.6.26.2 running on Slackware 12 # what host kernel arch you are using (i386 or x86_64) # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y Should I be using 64 bit ? # what guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version Slackware 11, but with a new standard (no patches) kernel - 2.6.26.2 I also have an older Slackware 7 based guest with a 2.4.29 SMP kernel that sees the lock-up, with qemu console working problem, but not the Zombie issue. The 2.4.29 kernel uses a 1Gb memory model. # the qemu command line you are using to start the guest /usr/local/bin/qemu-system-x86_64 -hda /opt/kvm/machine_14/vdisk1.img \ -m 1024 -vnc :14 -k en-gb -smp 4 \ -net nic,model=e1000,macaddr=52:54:00:14:00:00 -net tap \ -net nic,vlan=2,model=e1000,macaddr=52:54:00:14:00:01 \ -net tap,vlan=2,ifname=tap55 \ # whether the problem goes away if using the -no-kvm-irqchip or -no-kvm-pit switch. Not tried # whether the problem also appears with the -no-kvm switch. I don't use this switch. James -- 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
From: Christian Ehrhardt [EMAIL PROTECTED] 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 ppc. [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
w2k does not boot when using boot=on flag - Disk I/O Error?
Hi all, I am working on KVM 75 (Debian 2.6.24 amd64 Kernel, but the error is also on KVM 71, others not tested) ___ Disk I/o error: Status = 0001 Disk I/o error: Status = 0001 Disk I/o error: Status = 0001 Windows 2000 could not start because the following file is missing or corrupt: windows 2000 root\system32\ntoskrnl.exe. ___ I used the following command: With boot=on option: /usr/bin/kvm -smp 1 -localtime -k de -drive file=/var/lib/vz/images/115/vm-115-disk.qcow2,if=ide,index=0,boot=on -drive file=/var/lib/vz/template/iso/EN_WINDOWS_2000_PRO_SERVER_ADVSERVER.ISO,if=ide,index=2,media=cdrom -m 512 -net tap -net nic Without the boot=on option everything works: /usr/bin/kvm -smp 1 -localtime -k de -drive file=/var/lib/vz/images/115/vm-115-disk.qcow2,if=ide,index=0 -drive file=/var/lib/vz/template/iso/EN_WINDOWS_2000_PRO_SERVER_ADVSERVER.ISO,if=ide,index=2,media=cdrom -m 512 -net tap -net nic Any ideas? Br, Martin -- 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] 8139cp problems - steps to reproduce
Nikola, can you try: ifconfig tapX txqueuelen 1500 on the host, this work around solved my problem, well at least it doesn't hang every few miniutes. On Tue, Sep 16, 2008 at 8:34 AM, Nikola Ciprich [EMAIL PROTECTED] wrote: Hi David, well, I tried e1000, but it's actualy much worse for me. But I'm using much newer (vanilla) kernels, maybe RHEL kernels contain some patch that prevents the problem? I'll have a look. BR nik -- 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
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
Re: [PATCH] Make KVM compile on split source/object kernel configurations
On Sep 16, 2008, at 9:22 AM, Zhang, Xiantao wrote: 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. Hi, Graf what problems did you meet when building kvm/ia64 ? Xiantao This is the list of stuff I had to modify to get kvm-74 to run. I haven't tried anything more recent yet. 1) -mno-sdata does not work. Qemu CFLAGS need to be -msdata 2) In qemu/ia64.ld SEARCH_DIR is invalid for SUSE. It shouldn't search in /usr/ia64-linux but in /usr/ia64-suse-linux. 3) TARGET_PAGE_BITS is wrong 4) kernel/ia64/Makefile.pre assumes to find .S files in $KERNELDIR. They are in $SOURCEDIR. 5) kernel/ia64/Makefile.pre suffers from the same problem my original fix for x86 addressed. 6) The IA64 kernel build system is broken. The file asm-ia64/nr-irqs.h gets generated during the kernel build, but is not exported as obj, so it won't be in the split obj directory. Since the source-dir is clean though, the file simply does not exist on SUSE rpms. I will attach the patch I use in our local buildsystem to make KVM compile on IA64. Please do not take this as fixes, most of them are simple workarounds and should rather be fixed properly. We were just hitting deadlines internally. Alex IA64-kvm-suse.patch Description: Binary data
RE: [PATCH] Make KVM compile on split source/object kernel configurations
Alexander Graf wrote: On Sep 16, 2008, at 9:22 AM, Zhang, Xiantao wrote: 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. Hi, Graf what problems did you meet when building kvm/ia64 ? Xiantao This is the list of stuff I had to modify to get kvm-74 to run. I haven't tried anything more recent yet. 1) -mno-sdata does not work. Qemu CFLAGS need to be -msdata Which version of GCC are you using ? 2) In qemu/ia64.ld SEARCH_DIR is invalid for SUSE. It shouldn't search in /usr/ia64-linux but in /usr/ia64-suse-linux. You can make a patch to fix it. 3) TARGET_PAGE_BITS is wrong Currently, we just set TARGET_PAGE_BITS to 16 by hardcoding in Qemu. In the future, we should add the logic to make it equal to kernel's PAGE_SHIFT. 4) kernel/ia64/Makefile.pre assumes to find .S files in $KERNELDIR. They are in $SOURCEDIR. There is no issue here, I think. You have to set corrent $KERNELDIR through ./configure --kerneldir= once target machine and build machine is not same. 5) kernel/ia64/Makefile.pre suffers from the same problem my original fix for x86 addressed. Ditto. 6) The IA64 kernel build system is broken. The file asm-ia64/nr-irqs.h gets generated during the kernel build, but is not exported as obj, so it won't be in the split obj directory. Since the source-dir is clean though, the file simply does not exist on SUSE rpms. You mean the source-dir is clean ? So the generated header files including (linux/autoconf.h, asm-offsets.h...)should be removed wholely? I don't think they can be built with a clean source for most modules. I will attach the patch I use in our local buildsystem to make KVM compile on IA64. Please do not take this as fixes, most of them are simple workarounds and should rather be fixed properly. We were just hitting deadlines internally. 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
Re: [PATCH] Make KVM compile on split source/object kernel configurations
On Sep 16, 2008, at 12:22 PM, Zhang, Xiantao wrote: Alexander Graf wrote: On Sep 16, 2008, at 9:22 AM, Zhang, Xiantao wrote: 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. Hi, Graf what problems did you meet when building kvm/ia64 ? Xiantao This is the list of stuff I had to modify to get kvm-74 to run. I haven't tried anything more recent yet. 1) -mno-sdata does not work. Qemu CFLAGS need to be -msdata Which version of GCC are you using ? # gcc --version gcc (SUSE Linux) 4.3.2 20080815 (prerelease) [gcc-4_3-branch revision 139129] 2) In qemu/ia64.ld SEARCH_DIR is invalid for SUSE. It shouldn't search in /usr/ia64-linux but in /usr/ia64-suse-linux. You can make a patch to fix it. Right, this one should be really easy to fix. 3) TARGET_PAGE_BITS is wrong Currently, we just set TARGET_PAGE_BITS to 16 by hardcoding in Qemu. In the future, we should add the logic to make it equal to kernel's PAGE_SHIFT. From what I read on the KVM IA64 ML, this is not the first time someone ran into this issue. Sounds like a really good idea to add the logic ;-). 4) kernel/ia64/Makefile.pre assumes to find .S files in $KERNELDIR. They are in $SOURCEDIR. There is no issue here, I think. You have to set corrent $KERNELDIR through ./configure --kerneldir= once target machine and build machine is not same. No, since $KERNELDIR is the build dir, as that one contains all the configurations. The source dir only contains the sources. 5) kernel/ia64/Makefile.pre suffers from the same problem my original fix for x86 addressed. Ditto. 6) The IA64 kernel build system is broken. The file asm-ia64/nr- irqs.h gets generated during the kernel build, but is not exported as obj, so it won't be in the split obj directory. Since the source-dir is clean though, the file simply does not exist on SUSE rpms. You mean the source-dir is clean ? So the generated header files including (linux/autoconf.h, asm-offsets.h...)should be removed wholely? I don't think they can be built with a clean source for most modules. This is what I'm talking about all the time :-). For SUSE kernels there are two distinct directories: # ls -l /usr/src drwxr-xr-x 24 root root 4096 Aug 27 14:51 linux-2.6.27-rc4- HEAD_20080825213702 drwxr-xr-x 3 root root 4096 Aug 25 23:28 linux-2.6.27-rc4- HEAD_20080825213702-obj whereas the normal directory contains the sources and the -obj directory contains all files that were generated during the build. Scratch that with the 2 rpm files - they are all in kernel-sources. # ls -l /usr/src/linux-2.6.27-rc4-HEAD_20080825213702-obj/ia64/default/ total 568 -rw-r--r-- 1 root root 76287 Aug 25 23:27 .config -rw-r--r-- 2 root root554 Aug 25 23:28 Makefile -rw-r--r-- 1 root root 468615 Aug 25 23:51 Module.symvers drwxr-xr-x 3 root root 4096 Aug 26 18:01 arch drwxr-xr-x 5 root root 4096 Aug 26 18:01 include drwxr-xr-x 2 root root 4096 Aug 26 18:01 include2 drwxr-xr-x 2 root root 4096 Aug 25 23:28 kernel drwxr-xr-x 6 root root 4096 Aug 26 18:01 scripts The problem is now that a lot of people assume these two directories to be one. This is the default mode when you compile a kernel. SUSE does not take this route though, and hasn't for quite a while now. I don't know about other distributions, but I guess we're not the only ones ;-). 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
VMX: Host NMI triggering on NMI vmexit
Sheng, out of curiosity: vmx_vcpu_run invokes 'int $2' to trigger a host NMI if the VM exited due to an external NMI event. According to Intel specs I have, software-triggered NMIs do not block hardware NMIs. So are we facing the risk to receive another NMI while running the first handler? Or will the VM be left with the hardware blocking logic armed? Or does Linux not care about NMI handler re-entrance? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stability issue with KVM using SMP
Further to my previous report.. I have just noticed that, where the host is running on the dual Quad-Core AMD Opteron(tm) Processor 2352 (family 16, model 2) the kernels in the *guest* machines (usually 2.6.26) are reporting WARNING: This combination of AMDprocessors is not suitable for SMP. - presumably this is why my SMP isn't stable! The kernel in that host machine (2.6.26.2) does *not* report the messages. However, where the host is a single AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ (family 15, model 107) the guest kernels do not report the WARNING above - but I've not actually run any SMP guest on that host, so don't know if it would work or not. The warning seems to be due to a processor capability test in arch/x86/kernel/smpboot.c - add_taint(TAINT_UNSAFE_SMP); Its not clear to me why one guess is failing this test and the other passing, because both guests are seeing QEMU Virtual CPU version 0.9.1, family 6, model 2 (according to /proc/cpuinfo). Although most kernels on the Athlon host are running 2.6.21 not 2.6.26 James -- 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] KVM: Device Assignment with VT-d
Le mardi 16 septembre 2008 à 00:58 +, Avi Kivity a écrit :
From: Ben-Ami Yassour [EMAIL PROTECTED]
Based on a patch by: Kay, Allen M [EMAIL PROTECTED]
This patch enables PCI device assignment based on VT-d support.
When a device is assigned to the guest, the guest memory is pinned and
the mapping is updated in the VT-d IOMMU.
[Amit: Expose KVM_CAP_IOMMU so we can check if an IOMMU is present
and also control enable/disable from userspace]
Signed-off-by: Kay, Allen M [EMAIL PROTECTED]
Signed-off-by: Weidong Han [EMAIL PROTECTED]
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
Signed-off-by: Amit Shah [EMAIL PROTECTED]
Acked-by: Mark Gross [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index d0e940b..3072b17 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,6 +12,9 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
i8254.o
+ifeq ($(CONFIG_DMAR),y)
+kvm-objs += vtd.o
+endif
obj-$(CONFIG_KVM) += kvm.o
kvm-intel-objs = vmx.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
new file mode 100644
index 000..667bf3f
--- /dev/null
+++ b/arch/x86/kvm/vtd.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2006, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Copyright (C) 2006-2008 Intel Corporation
+ * Copyright IBM Corporation, 2008
+ * Author: Allen M. Kay [EMAIL PROTECTED]
+ * Author: Weidong Han [EMAIL PROTECTED]
+ * Author: Ben-Ami Yassour [EMAIL PROTECTED]
+ */
+
+#include linux/list.h
+#include linux/kvm_host.h
+#include linux/pci.h
+#include linux/dmar.h
+#include linux/intel-iommu.h
+
+static int kvm_iommu_unmap_memslots(struct kvm *kvm);
+static void kvm_iommu_put_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages);
+
+int kvm_iommu_map_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages)
+{
+ gfn_t gfn = base_gfn;
+ pfn_t pfn;
+ int i, r;
+ struct dmar_domain *domain = kvm-arch.intel_iommu_domain;
+
+ /* check if iommu exists and in use */
+ if (!domain)
+ return 0;
+
+ r = -EINVAL;
+ for (i = 0; i npages; i++) {
+ /* check if already mapped */
+ pfn = (pfn_t)intel_iommu_iova_to_pfn(domain,
+ gfn_to_gpa(gfn));
+ if (pfn !is_mmio_pfn(pfn))
+ continue;
+
+ pfn = gfn_to_pfn(kvm, gfn);
+ if (!is_mmio_pfn(pfn)) {
+ r = intel_iommu_page_mapping(domain,
+ gfn_to_gpa(gfn),
+ pfn_to_hpa(pfn),
+ PAGE_SIZE,
+ DMA_PTE_READ |
+ DMA_PTE_WRITE);
+ if (r) {
+ printk(KERN_DEBUG kvm_iommu_map_pages:
+iommu failed to map pfn=%lx\n, pfn);
+ goto unmap_pages;
+ }
+ } else {
+ printk(KERN_DEBUG kvm_iommu_map_page:
+invalid pfn=%lx\n, pfn);
+ goto unmap_pages;
+ }
+ gfn++;
+ }
+ return 0;
+
+unmap_pages:
+ kvm_iommu_put_pages(kvm, base_gfn, i);
+ return r;
+}
+
+static int kvm_iommu_map_memslots(struct kvm *kvm)
+{
+ int i, r;
+
+ down_read(kvm-slots_lock);
+ for (i = 0; i kvm-nmemslots; i++) {
+ r = kvm_iommu_map_pages(kvm, kvm-memslots[i].base_gfn,
+ kvm-memslots[i].npages);
+ if (r)
+ break;
+ }
+ up_read(kvm-slots_lock);
+ return r;
+}
+
+int kvm_iommu_map_guest(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *assigned_dev)
+{
+ struct pci_dev *pdev = NULL;
+ int r;
+
+ if (!intel_iommu_found()) {
+ printk(KERN_ERR %s:
kvmnet.sys BSOD w/ WinXP...
When using Windows XP 32 installed with TCP/IP and microsoft client networking, I can reproduce an intermittent BSOD [1] with kvmnet.sys 1.0.0 and 1.2.0, by aborting a large data transfer in an application. Since this reproduces with 1.0.0 kvmnet.sys, it looks unrelated to the locking changes that went into 1.2.0, but something relating to when sockets are closed, flushed or data discarded. Perhaps the offset into the driver at 0xF761A5A9 - 0xF7618000 may tell us what is needed to reproduce and hint at what area the fix is needed in? Many thanks, Daniel --- [1] DRIVER_IRQL_NOT_LESS_OR_EQUAL *** STOP: 0x00D1 (0x001C,0x0002,0x,0xF761A5A9) *** kvmnet.sys - Address F761A5A9 base at F7618000, DateStamp 47dd531c -- Daniel J Blueman -- 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
virtio performance issue
I am running virtio with the latest KVM code, and see a significant performance issue. Ping to the host (or any other close machine) reports a 4ms delay. In the same setup with an e1000 emulation (just changing model=virtio to model=e1000 in the KVM command line), ping reports 0.177ms delay. BTW, initially I saw that the throughput when using netperf is very low, even from guest to host, even though the CPU utilization is low. What might be the problem? Thanks, Ben -- 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-2114277 ] Boot progression fails to boot local disk after PXE
Bugs item #2114277, was opened at 2008-09-16 09:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2114277group_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: Rob Snow (robsnow31) Assigned to: Nobody/Anonymous (nobody) Summary: Boot progression fails to boot local disk after PXE Initial Comment: Tested with KVM-74 If you set boot priority to -nc (network, disk) If you have a pxelinux.cfg file that sets the host to localboot the VM ends the PXE boot correctly and then says it is Booting local disk, but fails right through (no delay, moves on) and then tries to PXE again starting a infinite loop of this. Here is an example pxelinux.cfg file that shows this issue: BEGIN /tftpboot/pxelinux.cfg/default default linux label linux localboot 0 END -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2114277group_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: virtio performance issue
Ben-Ami Yassour wrote: I am running virtio with the latest KVM code, and see a significant performance issue. Ping to the host (or any other close machine) reports a 4ms delay. What kvm version and what host kernel version? It's very easy to mistakenly compile qemu without GSO support too. You have to make sure that the 2.6.27 if_tun.h is being included by QEMU. Regards, Anthony Liguori In the same setup with an e1000 emulation (just changing model=virtio to model=e1000 in the KVM command line), ping reports 0.177ms delay. BTW, initially I saw that the throughput when using netperf is very low, even from guest to host, even though the CPU utilization is low. What might be the problem? Thanks, Ben -- 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] Refactor AIO to allow multiple AIO implementations
This patch refactors the AIO layer to allow multiple AIO implementations. It's
only possible because of the recent signalfd() patch.
Right now, the AIO infrastructure is pretty specific to the block raw backend.
For other block devices to implement AIO, the qemu_aio_wait function must
support registration. This patch introduces a new function,
qemu_aio_set_fd_handler, which can be used to register a file descriptor to be
called back. qemu_aio_wait() now polls a set of file descriptors registered
with this function until one becomes readable or writable.
This patch should allow the implementation of alternative AIO backends (via a
thread pool or linux-aio) and AIO backends in non-traditional block devices
(like NBD).
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/Makefile b/Makefile
index 7bb2bf2..de6393e 100644
--- a/Makefile
+++ b/Makefile
@@ -51,7 +51,7 @@ BLOCK_OBJS=cutils.o qemu-malloc.o
BLOCK_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o
BLOCK_OBJS+=block-dmg.o block-bochs.o block-vpc.o block-vvfat.o
BLOCK_OBJS+=block-qcow2.o block-parallels.o block-nbd.o
-BLOCK_OBJS+=nbd.o block.o
+BLOCK_OBJS+=nbd.o block.o aio.o
ifdef CONFIG_WIN32
BLOCK_OBJS += block-raw-win32.o
diff --git a/Makefile.target b/Makefile.target
index 91967ec..0856d3f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -472,7 +472,7 @@ endif #CONFIG_DARWIN_USER
# System emulator target
ifndef CONFIG_USER_ONLY
-OBJS=vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o machine.o net-checksum.o
+OBJS=vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o machine.o net-checksum.o
aio.o
ifdef CONFIG_WIN32
OBJS+=block-raw-win32.o
else
diff --git a/aio.c b/aio.c
new file mode 100644
index 000..687e4be
--- /dev/null
+++ b/aio.c
@@ -0,0 +1,192 @@
+/*
+ * QEMU aio implementation
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ * Anthony Liguori [EMAIL PROTECTED]
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include qemu-common.h
+#include block.h
+#include sys-queue.h
+#include qemu_socket.h
+
+typedef struct AioHandler AioHandler;
+
+/* The list of registered AIO handlers */
+static LIST_HEAD(, AioHandler) aio_handlers;
+
+/* This is a simple lock used to protect the aio_handlers list. Specifically,
+ * it's used to ensure that no callbacks are removed while we're walking and
+ * dispatching callbacks.
+ */
+static int walking_handlers;
+
+struct AioHandler
+{
+int fd;
+IOHandler *io_read;
+IOHandler *io_write;
+AioFlushHandler *io_flush;
+int deleted;
+void *opaque;
+LIST_ENTRY(AioHandler) node;
+};
+
+static AioHandler *find_aio_handler(int fd)
+{
+AioHandler *node;
+
+LIST_FOREACH(node, aio_handlers, node) {
+if (node-fd == fd)
+return node;
+}
+
+return NULL;
+}
+
+int qemu_aio_set_fd_handler(int fd,
+IOHandler *io_read,
+IOHandler *io_write,
+AioFlushHandler *io_flush,
+void *opaque)
+{
+AioHandler *node;
+
+node = find_aio_handler(fd);
+
+/* Are we deleting the fd handler? */
+if (!io_read !io_write) {
+if (node) {
+/* If the lock is held, just mark the node as deleted */
+if (walking_handlers)
+node-deleted = 1;
+else {
+/* Otherwise, delete it for real. We can't just mark it as
+ * deleted because deleted nodes are only cleaned up after
+ * releasing the walking_handlers lock.
+ */
+LIST_REMOVE(node, node);
+qemu_free(node);
+}
+}
+} else {
+if (node == NULL) {
+/* Alloc and insert if it's not already there */
+node = qemu_mallocz(sizeof(AioHandler));
+if (node == NULL)
+return -ENOMEM;
+node-fd = fd;
+LIST_INSERT_HEAD(aio_handlers, node, node);
+}
+/* Update handler with latest information */
+node-io_read = io_read;
+node-io_write = io_write;
+node-io_flush = io_flush;
+node-opaque = opaque;
+}
+
+qemu_set_fd_handler2(fd, NULL, io_read, io_write, opaque);
+
+return 0;
+}
+
+void qemu_aio_flush(void)
+{
+AioHandler *node;
+int ret;
+
+do {
+ret = 0;
+
+LIST_FOREACH(node, aio_handlers, node) {
+ret |= node-io_flush(node-opaque);
+}
+
+qemu_aio_wait();
+} while (ret 0);
+}
+
+void qemu_aio_wait(void)
+{
+int ret;
+
+if (qemu_bh_poll())
+return;
+
+do {
+AioHandler *node;
+fd_set rdfds, wrfds;
+int max_fd = -1;
+
+walking_handlers = 1;
+
+/* fill fd sets */
+LIST_FOREACH(node, aio_handlers, node) {
+/* If there aren't pending AIO
[PATCH] KVM: x86: Fix compile when CONFIG_DMAR is not defined
intel_iommu_found() is not defined if CONFIG_DMAR is not defined
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
include/linux/kvm_host.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6252802..5b9d713 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -331,6 +331,11 @@ static inline int kvm_iommu_unmap_guest(struct kvm *kvm)
{
return 0;
}
+
+static inline int intel_iommu_found()
+{
+ return 0;
+}
#endif /* CONFIG_DMAR */
static inline void kvm_guest_enter(void)
--
1.5.4.3
--
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] KVM: x86: Fix compile when CONFIG_DMAR is not defined
Amit Shah wrote:
intel_iommu_found() is not defined if CONFIG_DMAR is not defined
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
include/linux/kvm_host.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6252802..5b9d713 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -331,6 +331,11 @@ static inline int kvm_iommu_unmap_guest(struct kvm *kvm)
{
return 0;
}
+
+static inline int intel_iommu_found()
+{
+ return 0;
+}
#endif /* CONFIG_DMAR */
static inline void kvm_guest_enter(void)
in linux/intel-iommu.h
--
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
[PATCH] KVM: x86: Fix compile when CONFIG_DMAR is not defined
intel_iommu_found() is not defined if CONFIG_DMAR is not defined
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
include/linux/intel-iommu.h | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 1490fc0..5fa9d26 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -349,7 +349,15 @@ int intel_iommu_page_mapping(struct dmar_domain *domain,
dma_addr_t iova,
u64 hpa, size_t size, int prot);
void intel_iommu_detach_dev(struct dmar_domain *domain, u8 bus, u8 devfn);
struct dmar_domain *intel_iommu_find_domain(struct pci_dev *pdev);
-int intel_iommu_found(void);
u64 intel_iommu_iova_to_pfn(struct dmar_domain *domain, u64 iova);
+#ifdef CONFIG_DMAR
+int intel_iommu_found(void);
+#else /* CONFIG_DMAR */
+static inline int intel_iommu_found(void)
+{
+ return 0;
+}
+#endif /* CONFIG_DMAR */
+
#endif
--
1.5.4.3
--
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/1] Add configure script check for gawk when using kvm-userspace.git
When building kvm-userspace from git, gawk is used by kernel/Makefile. Without this check it's non-obvious why kernel/Makefile fails. Signed-off-by: Brian Jackson [EMAIL PROTECTED] diff --git a/configure b/configure index 3bb10ce..5cac4c8 100755 --- a/configure +++ b/configure @@ -102,6 +102,12 @@ if [ $arch = powerpc ]; then qemu_ldflags=$qemu_ldflags -L $PWD/libfdt fi +# check for some utils we use +if [ -d .git -a ! -x `which gawk` ] ; then +echo gawk not installed and necessary for compiling from git +exit 1 +fi + #configure user dir (cd user; ./configure --prefix=$prefix --kerneldir=$libkvm_kerneldir \ --arch=$arch \ -- 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] KVM: Device Assignment: Free device structures if IRQ allocation fails
* On Tuesday 16 Sep 2008 22:55:29 Avi Kivity wrote: Amit Shah wrote: When an IRQ allocation fails, we free up the device structures and disable the device so that we can unregister the device in the userspace and not expose it to the guest at all. Still doesn't apply. What did you generate this against? Please use the newer one that I sent you a while back. -- 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: virtio performance issue
Ben-Ami Yassour [EMAIL PROTECTED] wrote: Hello Ben, I am running virtio with the latest KVM code, and see a significant performance issue. Ping to the host (or any other close machine) reports a 4ms delay. In the same setup with an e1000 emulation (just changing model=virtio to model=e1000 in the KVM command line), ping reports 0.177ms delay. BTW, initially I saw that the throughput when using netperf is very low, even from guest to host, even though the CPU utilization is low. What might be the problem? I had exactly the same issue (with an 2.6.26 kernel and kvm-70 though). In an attempt to make the guest kernel (w/o modules) as small as possible I had disabled ACPI in its config. Which works, but introduced the very same 4ms delay you are seeing and made the VM clock go wild (even worse with KVM_CLOCK). I did not see other speed issues, but I have to admit I never benchmarked it. After enabling ACPI the 4ms delay baseline disappeared and the clock in the guest is now perfectly in sync with the host. Regards, Bernhard -- 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] Refactor AIO to allow multiple AIO implementations
On 9/16/08, Anthony Liguori [EMAIL PROTECTED] wrote: This patch refactors the AIO layer to allow multiple AIO implementations. It's only possible because of the recent signalfd() patch. +/* This is a simple lock used to protect the aio_handlers list. Specifically, + * it's used to ensure that no callbacks are removed while we're walking and + * dispatching callbacks. + */ +static int walking_handlers; Shouldn't this be volatile and/or atomic_t? Just wondering, why don't you use real locking operations, for example those in qemu-lock.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
[PATCH] KVM/userspace: Support for assigning PCI devices to guests
[This still doesn't include some fixes to review comments.
I'm posting this just so that people can use this to test
or base their work off the latest patch.]
From: Or Sagi [EMAIL PROTECTED]
From: Nir Peleg [EMAIL PROTECTED]
From: Amit Shah [EMAIL PROTECTED]
From: Ben-Ami Yassour [EMAIL PROTECTED]
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
With this patch, we can assign a device on the host machine to a
guest.
A new command-line option, -pcidevice is added.
For example, to invoke it for a device sitting at PCI bus:dev.fn
04:08.0 with host IRQ 18, use this:
-pcidevice host=04:08.0
The host driver for the device, if any, is to be removed before
assigning the device.
This works only with the in-kernel irqchip method; to use the
userspace irqchip, a kernel module (irqhook) and some extra changes
are needed.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 14 ++
libkvm/libkvm.h | 27 +++
qemu/Makefile.target |1 +
qemu/hw/isa.h|2 ++
qemu/hw/pc.c |9 +
qemu/hw/pci.c| 12
qemu/hw/pci.h|1 +
qemu/hw/piix_pci.c | 19 +++
qemu/qemu-kvm-x86.c |3 +++
qemu/vl.c| 18 ++
10 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index a8cca15..6157f75 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -53,6 +53,20 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
}
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_PCI_DEVICE, assigned_dev);
+}
+
+int kvm_assign_irq(kvm_context_t kvm,
+ struct kvm_assigned_irq *assigned_irq)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_IRQ, assigned_irq);
+}
+#endif
+
int kvm_create_pit(kvm_context_t kvm)
{
#ifdef KVM_CAP_PIT
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 79dd769..edf8e9e 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -658,4 +658,31 @@ int kvm_s390_interrupt(kvm_context_t kvm, int slot,
int kvm_s390_set_initial_psw(kvm_context_t kvm, int slot, psw_t psw);
int kvm_s390_store_status(kvm_context_t kvm, int slot, unsigned long addr);
#endif
+
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+/*!
+ * \brief Notifies host kernel aboud a PCI device assigned to guest
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the physical PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_dev Parameters, like bus, devfn number, etc
+ */
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev);
+
+/*!
+ * \brief Notifies host kernel about changes to a irq assignment
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the irq for an assigned physical
+ * PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_irq Parameters, like dev id, host irq, guest irq, etc
+ */
+int kvm_assign_irq(kvm_context_t kvm,
+ struct kvm_assigned_irq *assigned_irq);
+#endif
#endif
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 89814fd..958c33b 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -611,6 +611,7 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o
+OBJS+= device-assignment.o
ifeq ($(USE_KVM_PIT), 1)
OBJS+= i8254-kvm.o
endif
diff --git a/qemu/hw/isa.h b/qemu/hw/isa.h
index 89b3004..c720f5e 100644
--- a/qemu/hw/isa.h
+++ b/qemu/hw/isa.h
@@ -1,5 +1,7 @@
/* ISA bus */
+#include hw.h
+
extern target_phys_addr_t isa_mem_base;
int register_ioport_read(int start, int length, int size,
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 8a50096..59c2098 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -32,6 +32,7 @@
#include smbus.h
#include boards.h
#include console.h
+#include device-assignment.h
#include qemu-kvm.h
@@ -1013,6 +1014,14 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size,
}
}
+/* Initialize assigned devices */
+if (pci_enabled) {
+int r = -1;
+do {
+init_assigned_device(pci_bus, r);
+ } while (r = 0);
+}
+
rtc_state = rtc_init(0x70, i8259[8]);
qemu_register_boot_set(pc_boot_set, rtc_state);
diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
index 07d37a8..e4e8386 100644
--- a/qemu/hw/pci.c
+++ b/qemu/hw/pci.c
@@ -50,6 +50,7 @@ struct PCIBus {
static void pci_update_mappings(PCIDevice *d);
static void pci_set_irq(void *opaque, int irq_num, int level);
+void assigned_dev_update_irq(PCIDevice
[ kvm-Bugs-2019053 ] tbench fails on guest when AMD NPT enabled
Bugs item #2019053, was opened at 2008-07-15 18:10 Message generated for change (Comment added) made by alex_williamson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2019053group_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: amd Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Alex Williamson (alex_williamson) Assigned to: Nobody/Anonymous (nobody) Summary: tbench fails on guest when AMD NPT enabled Initial Comment: Running on a dual-socket system with AMD 2356 quad-core processors (8 total cores), 32GB RAM, Ubuntu Hardy 2.6.24-19-generic (64bit) with kvm-71 userspace and kernel modules. With no module options, dmesg confirms: kvm: Nested Paging enabled Start guest with: /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/VM/Ubuntu64 -m 1024 -net nic,model=e1000,mac=de:ad:be:ef:00:01 -net tap,script=/root/bin/br0-ifup -smp 8 -vnc :0 Guest VM is also Ubuntu Hardy 64bit. On the guest run 'tbench 16 tbench server'. System running tbench_srv is a different system in my case. The tbench client will fail randomly, often quietly with Child failed with status 1, but sometimes more harshly with a glibc double free error. If I unload the modules and reload w/o npt: modprobe -r kvm-amd modprobe -r kvm modprobe kvm-amd npt=0 dmesg confirms: kvm: Nested Paging disabled The tbench test now runs over and over successfully. The test also runs fine on an Intel E5450 (no EPT). -- Comment By: Alex Williamson (alex_williamson) Date: 2008-09-16 12:16 Message: Fixed in KVM-75 by kvm.git commit 6eaa802ce5187e8508b07293633af00d8ccc911b -- Comment By: Alex Williamson (alex_williamson) Date: 2008-09-02 10:36 Message: Logged In: YES user_id=333914 Originator: YES vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : Quad-Core AMD Opteron(tm) Processor 2356 stepping: 3 cpu MHz : 2300.080 cache size : 512 KB physical id : 1 siblings: 4 core id : 3 cpu cores : 4 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips: 4601.00 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate -- Comment By: Joerg Roedel (jroedel) Date: 2008-09-02 07:27 Message: Logged In: YES user_id=2019182 Originator: NO Hi Alex, can you post the model and stepping from /proc/cpuinfo of the host you reproduced the issue? This would be very helpfull. Thanks, Joerg -- Comment By: Alexander Graf (awwy) Date: 2008-07-25 03:30 Message: Logged In: YES user_id=376328 Originator: NO I just tried my test on openSUSE 10.3 again and it fails now. This bug really only shows itself rarely - out of 30 kernel build usually about 5 fail. So scratch the 2.6.22 idea. We're back at square 1. -- Comment By: Alex Williamson (alex_williamson) Date: 2008-07-24 11:10 Message: Logged In: YES user_id=333914 Originator: YES I tried the Ubuntu Gutsy 2.6.22-15-generic kernel on the host, but I still see the issue. I'll install openSUSE 10.3 and see what happens. -- Comment By: Alexander Graf (awwy) Date: 2008-07-23 23:45 Message: Logged In: YES user_id=376328 Originator: NO I'm seeing random segfaults when using NPT on a host kernel = 2.6.23. So far I have not been able to reproduce my test case breakages with an openSUSE 10.3 kernel though, so could you please test that and verify if tbench works for you on openSUSE 10.3? It does break with 11.0. I have the feeling that we're seeing the same problem here. -- Comment By: Alex Williamson (alex_williamson) Date: 2008-07-16 09:18 Message: Logged In: YES user_id=333914 Originator: YES No, I added mlockall(MCL_CURRENT | MCL_FUTURE) to qemu/vl.c:main() and it makes no difference. I'm only starting a 1G guest on an otherwise idle 32G host, so host memory pressure is pretty light. -- Comment By:
Re: [PATCH] KVM: Device Assignment with VT-d
Laurent Vivier wrote: @@ -1147,6 +1157,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_PV_MMU: r = !tdp_enabled; break; + case KVM_CAP_IOMMU: + r = intel_iommu_found(); + break; Must depend on CONFIG_DMAR too Rather, intel_iommu_found() should be defined (and return zero) if !CONFIG_DMAR. (what's a dmar?) -- 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: [Qemu-devel] [PATCH] Refactor AIO to allow multiple AIO implementations
Blue Swirl wrote: On 9/16/08, Anthony Liguori [EMAIL PROTECTED] wrote: This patch refactors the AIO layer to allow multiple AIO implementations. It's only possible because of the recent signalfd() patch. +/* This is a simple lock used to protect the aio_handlers list. Specifically, + * it's used to ensure that no callbacks are removed while we're walking and + * dispatching callbacks. + */ +static int walking_handlers; Shouldn't this be volatile and/or atomic_t? No, because this is just used to protect the aio_handlers list within the same thread. Here's the scenario we're protecting: Walk aio_handlers list = call handler = handler calls qemu_aio_set_fd_handler() to delete aio entry Since we're walking the list, we can't delete an entry while walking. This is the same problem we have in vl.c with the IOHandler list. Unlike the IOHandler list, we don't walk the aio_handler list often enough to just set a flag on the entry. In the case where qemu_aio_set_fd_handler() is called from something other than a handler callback, we need to be able to directly delete the entry element. This is why we use the lock, to detect that case. It's not a real lock, because two threads are never trying to access it at the same time. This is why we don't need volatile, atomic_t, or the real locking primitives. Regards, Anthony Liguori Just wondering, why don't you use real locking operations, for example those in qemu-lock.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: virtio performance issue
On Tue, 2008-09-16 at 09:16 -0500, Anthony Liguori wrote: Ben-Ami Yassour wrote: I am running virtio with the latest KVM code, and see a significant performance issue. Ping to the host (or any other close machine) reports a 4ms delay. What kvm version and what host kernel version? It's very easy to mistakenly compile qemu without GSO support too. You have to make sure that the 2.6.27 if_tun.h is being included by QEMU. Is there an option to control GSO support? How? I am using the kernel and userspace that I pulled from the kvm tree today. Based on your comment, we checked and the build of the userspace does not take if_tun.h from the kernel tree, it takes it from the system include files. The reason was that the file was not copied as part of the userspace build. To fix this we made the following change: diff --git a/kernel/Makefile b/kernel/Makefile index 3f5f6da..b81b098 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -53,7 +53,7 @@ T = $(subst -sync,,$@)-tmp header-sync: rm -rf $T rsync -R \ -$(LINUX)/./include/linux/kvm*.h \ +$(LINUX)/./include/linux/*.h \ $(LINUX)/./include/asm-*/kvm*.h \ Even with this change and compiling the userspace with the correct if_tun.h the results are the same, ping takes 4ms. What could be the reason? Thanks, Ben -- 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
add_usb and usb_linux_update_endp_table: Connection timed out
check out for qemu's -serial option Only some operations do work this way. The atmel controller signature is read wrongly from the device all the time using this option. I'd like to try an USB to serial adapter now. using usb_add host:1.2 or such I am able to attach the harddisk and WindowsXP even tells me that it could perform better when beeing attached to an USB 2.0 adapter. But XP itself gets really slow and does'nt add an addiotianl drive letter. Adding my serial cable this way I get a line printed on stdout/err: usb_linux_update_endp_table: Connection timed out and Could not add USB device `host:7.2` Is this default behaviour? $ uname -r 2.6.25.16-default $ qemu-system-x86_64 QEMU PC emulator version 0.9.1 (kvm-72), Copyright (c) 2003-2008 Fabrice Bellard Sincerly Marc -- 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] KVM: Device Assignment: Free device structures if IRQ allocation fails
Amit Shah wrote: * On Tuesday 16 Sep 2008 22:55:29 Avi Kivity wrote: Amit Shah wrote: When an IRQ allocation fails, we free up the device structures and disable the device so that we can unregister the device in the userspace and not expose it to the guest at all. Still doesn't apply. What did you generate this against? Please use the newer one that I sent you a while back. Okay, got it. The [PATCH v18] thing can help prevent such confusion. -- 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: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: as i see only the first iso is corrupt, so here is the first iso: ftp://ftp.bppiac.hu/ Well, it installs and runs perfectly. Can you describe what's going wrong? What's your host cpu? -- 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
[patch 0/2] switch to get_user_pages_fast
-- -- 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/2] KVM: opencode gfn_to_page in kvm_vm_fault
kvm_vm_fault is invoked with mmap_sem held in read mode. Since gfn_to_page
will be converted to get_user_pages_fast, which requires this lock NOT
to be held, switch to opencoded get_user_pages.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
Index: kvm.tip/virt/kvm/kvm_main.c
===
--- kvm.tip.orig/virt/kvm/kvm_main.c
+++ kvm.tip/virt/kvm/kvm_main.c
@@ -1394,17 +1394,22 @@ out:
static int kvm_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
+ struct page *page[1];
+ unsigned long addr;
+ int npages;
+ gfn_t gfn = vmf-pgoff;
struct kvm *kvm = vma-vm_file-private_data;
- struct page *page;
- if (!kvm_is_visible_gfn(kvm, vmf-pgoff))
+ addr = gfn_to_hva(kvm, gfn);
+ if (kvm_is_error_hva(addr))
return VM_FAULT_SIGBUS;
- page = gfn_to_page(kvm, vmf-pgoff);
- if (is_error_page(page)) {
- kvm_release_page_clean(page);
+
+ npages = get_user_pages(current, current-mm, addr, 1, 1, 0, page,
+ NULL);
+ if (unlikely(npages != 1))
return VM_FAULT_SIGBUS;
- }
- vmf-page = page;
+
+ vmf-page = page[0];
return 0;
}
--
--
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/2] KVM: switch to get_user_pages_fast
Convert gfn_to_pfn to use get_user_pages_fast, which can do lockless
pagetable lookups on x86. Kernel compilation on 4-way guest is 3.7%
faster on VMX.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
Index: kvm.tip/arch/x86/kvm/mmu.c
===
--- kvm.tip.orig/arch/x86/kvm/mmu.c
+++ kvm.tip/arch/x86/kvm/mmu.c
@@ -405,16 +405,19 @@ static int host_largepage_backed(struct
{
struct vm_area_struct *vma;
unsigned long addr;
+ int ret = 0;
addr = gfn_to_hva(kvm, gfn);
if (kvm_is_error_hva(addr))
- return 0;
+ return ret;
+ down_read(current-mm-mmap_sem);
vma = find_vma(current-mm, addr);
if (vma is_vm_hugetlb_page(vma))
- return 1;
+ ret = 1;
+ up_read(current-mm-mmap_sem);
- return 0;
+ return ret;
}
static int is_largepage_backed(struct kvm_vcpu *vcpu, gfn_t large_gfn)
@@ -1140,9 +1143,7 @@ struct page *gva_to_page(struct kvm_vcpu
if (gpa == UNMAPPED_GVA)
return NULL;
- down_read(current-mm-mmap_sem);
page = gfn_to_page(vcpu-kvm, gpa PAGE_SHIFT);
- up_read(current-mm-mmap_sem);
return page;
}
@@ -1330,16 +1331,14 @@ static int nonpaging_map(struct kvm_vcpu
pfn_t pfn;
unsigned long mmu_seq;
- down_read(current-mm-mmap_sem);
if (is_largepage_backed(vcpu, gfn ~(KVM_PAGES_PER_HPAGE-1))) {
gfn = ~(KVM_PAGES_PER_HPAGE-1);
largepage = 1;
}
mmu_seq = vcpu-kvm-mmu_notifier_seq;
- /* implicit mb(), we'll read before PT lock is unlocked */
+ smp_rmb();
pfn = gfn_to_pfn(vcpu-kvm, gfn);
- up_read(current-mm-mmap_sem);
/* mmio */
if (is_error_pfn(pfn)) {
@@ -1488,15 +1487,13 @@ static int tdp_page_fault(struct kvm_vcp
if (r)
return r;
- down_read(current-mm-mmap_sem);
if (is_largepage_backed(vcpu, gfn ~(KVM_PAGES_PER_HPAGE-1))) {
gfn = ~(KVM_PAGES_PER_HPAGE-1);
largepage = 1;
}
mmu_seq = vcpu-kvm-mmu_notifier_seq;
- /* implicit mb(), we'll read before PT lock is unlocked */
+ smp_rmb();
pfn = gfn_to_pfn(vcpu-kvm, gfn);
- up_read(current-mm-mmap_sem);
if (is_error_pfn(pfn)) {
kvm_release_pfn_clean(pfn);
return 1;
@@ -1809,15 +1806,13 @@ static void mmu_guess_page_from_pte_writ
return;
gfn = (gpte PT64_BASE_ADDR_MASK) PAGE_SHIFT;
- down_read(current-mm-mmap_sem);
if (is_large_pte(gpte) is_largepage_backed(vcpu, gfn)) {
gfn = ~(KVM_PAGES_PER_HPAGE-1);
vcpu-arch.update_pte.largepage = 1;
}
vcpu-arch.update_pte.mmu_seq = vcpu-kvm-mmu_notifier_seq;
- /* implicit mb(), we'll read before PT lock is unlocked */
+ smp_rmb();
pfn = gfn_to_pfn(vcpu-kvm, gfn);
- up_read(current-mm-mmap_sem);
if (is_error_pfn(pfn)) {
kvm_release_pfn_clean(pfn);
Index: kvm.tip/arch/x86/kvm/paging_tmpl.h
===
--- kvm.tip.orig/arch/x86/kvm/paging_tmpl.h
+++ kvm.tip/arch/x86/kvm/paging_tmpl.h
@@ -102,14 +102,10 @@ static bool FNAME(cmpxchg_gpte)(struct k
pt_element_t *table;
struct page *page;
- down_read(current-mm-mmap_sem);
page = gfn_to_page(kvm, table_gfn);
- up_read(current-mm-mmap_sem);
table = kmap_atomic(page, KM_USER0);
-
ret = CMPXCHG(table[index], orig_pte, new_pte);
-
kunmap_atomic(table, KM_USER0);
kvm_release_page_dirty(page);
@@ -418,7 +414,6 @@ static int FNAME(page_fault)(struct kvm_
return 0;
}
- down_read(current-mm-mmap_sem);
if (walker.level == PT_DIRECTORY_LEVEL) {
gfn_t large_gfn;
large_gfn = walker.gfn ~(KVM_PAGES_PER_HPAGE-1);
@@ -428,9 +423,8 @@ static int FNAME(page_fault)(struct kvm_
}
}
mmu_seq = vcpu-kvm-mmu_notifier_seq;
- /* implicit mb(), we'll read before PT lock is unlocked */
+ smp_rmb();
pfn = gfn_to_pfn(vcpu-kvm, walker.gfn);
- up_read(current-mm-mmap_sem);
/* mmio */
if (is_error_pfn(pfn)) {
Index: kvm.tip/arch/x86/kvm/vmx.c
===
--- kvm.tip.orig/arch/x86/kvm/vmx.c
+++ kvm.tip/arch/x86/kvm/vmx.c
@@ -2010,9 +2010,7 @@ static int alloc_apic_access_page(struct
if (r)
goto out;
- down_read(current-mm-mmap_sem);
kvm-arch.apic_access_page = gfn_to_page(kvm, 0xfee00);
- up_read(current-mm-mmap_sem);
out:
up_write(kvm-slots_lock);
return r;
@@ -2034,10 +2032,8 @@ static int alloc_identity_pagetable(stru
if (r)
goto out;
'Commit' command in monitor?
Using a recent QEMU tree (5001), I can start a Windows XP VM (FAT32-based) in -snapshot mode, make changes, shutdown Windows (I have auto-power-off disabled) and then issue 'commit all' at the monitor prompt. The changes which I have made are then correctly stored back into the image file (raw format) when I next run up the VM. Whenever I do the same thing with kvm-75, the image file is ruined when I next start up. Either I'll need to run scandisk and it will find and fix a battery of damaged directory entries, or it'll blue screen because some critical system file (e.g. registry hive) is missing. Is the code which implements 'commit' the same between vanilla QEMU and kvm's version? Is this supposed to work? Am I doing something wrong? Apologies that I have no additional troubleshooting info available. -- 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] KVM: Device Assignment with VT-d
On Tue, Sep 16, 2008 at 11:18:30AM -0700, Avi Kivity wrote: Laurent Vivier wrote: @@ -1147,6 +1157,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_PV_MMU: r = !tdp_enabled; break; + case KVM_CAP_IOMMU: + r = intel_iommu_found(); + break; Must depend on CONFIG_DMAR too Rather, intel_iommu_found() should be defined (and return zero) if !CONFIG_DMAR. (what's a dmar?) DMA Remapping Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 -- 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] KVM/userspace: Support for assigning PCI devices to guests
Seems it lacks device-assignment.[c,h] ?
Xiantao
Amit Shah wrote:
[This still doesn't include some fixes to review comments.
I'm posting this just so that people can use this to test
or base their work off the latest patch.]
From: Or Sagi [EMAIL PROTECTED]
From: Nir Peleg [EMAIL PROTECTED]
From: Amit Shah [EMAIL PROTECTED]
From: Ben-Ami Yassour [EMAIL PROTECTED]
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
With this patch, we can assign a device on the host machine to a
guest.
A new command-line option, -pcidevice is added.
For example, to invoke it for a device sitting at PCI bus:dev.fn
04:08.0 with host IRQ 18, use this:
-pcidevice host=04:08.0
The host driver for the device, if any, is to be removed before
assigning the device.
This works only with the in-kernel irqchip method; to use the
userspace irqchip, a kernel module (irqhook) and some extra changes
are needed.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 14 ++
libkvm/libkvm.h | 27 +++
qemu/Makefile.target |1 +
qemu/hw/isa.h|2 ++
qemu/hw/pc.c |9 +
qemu/hw/pci.c| 12
qemu/hw/pci.h|1 +
qemu/hw/piix_pci.c | 19 +++
qemu/qemu-kvm-x86.c |3 +++
qemu/vl.c| 18 ++
10 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index a8cca15..6157f75 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -53,6 +53,20 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
}
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_PCI_DEVICE, assigned_dev);
+}
+
+int kvm_assign_irq(kvm_context_t kvm,
+struct kvm_assigned_irq *assigned_irq)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_IRQ, assigned_irq);
+}
+#endif
+
int kvm_create_pit(kvm_context_t kvm)
{
#ifdef KVM_CAP_PIT
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 79dd769..edf8e9e 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -658,4 +658,31 @@ int kvm_s390_interrupt(kvm_context_t kvm, int
slot, int kvm_s390_set_initial_psw(kvm_context_t kvm, int slot,
psw_t psw); int kvm_s390_store_status(kvm_context_t kvm, int slot,
unsigned long addr); #endif
+
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+/*!
+ * \brief Notifies host kernel aboud a PCI device assigned to guest
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the physical PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_dev Parameters, like bus, devfn number, etc
+ */
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev);
+
+/*!
+ * \brief Notifies host kernel about changes to a irq assignment
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the irq for an assigned physical
+ * PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_irq Parameters, like dev id, host irq, guest irq,
etc + */
+int kvm_assign_irq(kvm_context_t kvm,
+struct kvm_assigned_irq *assigned_irq);
+#endif
#endif
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 89814fd..958c33b 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -611,6 +611,7 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o
+OBJS+= device-assignment.o
ifeq ($(USE_KVM_PIT), 1)
OBJS+= i8254-kvm.o
endif
diff --git a/qemu/hw/isa.h b/qemu/hw/isa.h
index 89b3004..c720f5e 100644
--- a/qemu/hw/isa.h
+++ b/qemu/hw/isa.h
@@ -1,5 +1,7 @@
/* ISA bus */
+#include hw.h
+
extern target_phys_addr_t isa_mem_base;
int register_ioport_read(int start, int length, int size,
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 8a50096..59c2098 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -32,6 +32,7 @@
#include smbus.h
#include boards.h
#include console.h
+#include device-assignment.h
#include qemu-kvm.h
@@ -1013,6 +1014,14 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size, }
}
+/* Initialize assigned devices */
+if (pci_enabled) {
+int r = -1;
+do {
+init_assigned_device(pci_bus, r);
+ } while (r = 0);
+}
+
rtc_state = rtc_init(0x70, i8259[8]);
qemu_register_boot_set(pc_boot_set, rtc_state);
diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
index 07d37a8..e4e8386 100644
--- a/qemu/hw/pci.c
+++
RE: [PATCH] KVM/userspace: Support for assigning PCI devices to guests
Amit Shah wrote:
[This still doesn't include some fixes to review comments.
I'm posting this just so that people can use this to test
or base their work off the latest patch.]
From: Or Sagi [EMAIL PROTECTED]
From: Nir Peleg [EMAIL PROTECTED]
From: Amit Shah [EMAIL PROTECTED]
From: Ben-Ami Yassour [EMAIL PROTECTED]
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
With this patch, we can assign a device on the host machine to a
guest.
A new command-line option, -pcidevice is added.
For example, to invoke it for a device sitting at PCI bus:dev.fn
04:08.0 with host IRQ 18, use this:
-pcidevice host=04:08.0
The host driver for the device, if any, is to be removed before
assigning the device.
This works only with the in-kernel irqchip method; to use the
userspace irqchip, a kernel module (irqhook) and some extra changes
are needed.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 14 ++
libkvm/libkvm.h | 27 +++
qemu/Makefile.target |1 +
qemu/hw/isa.h|2 ++
qemu/hw/pc.c |9 +
qemu/hw/pci.c| 12
qemu/hw/pci.h|1 +
qemu/hw/piix_pci.c | 19 +++
qemu/qemu-kvm-x86.c |3 +++
qemu/vl.c| 18 ++
10 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index a8cca15..6157f75 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -53,6 +53,20 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
}
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_PCI_DEVICE, assigned_dev);
+}
+
+int kvm_assign_irq(kvm_context_t kvm,
+struct kvm_assigned_irq *assigned_irq)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_IRQ, assigned_irq);
+}
+#endif
Could you move this part to libkvm.c? it should be shared by all archs,
I think.
Xiantao
--
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
Re: [PATCH] KVM/userspace: Support for assigning PCI devices to guests
* On Wednesday 17 Sep 2008 11:15:16 Zhang, Xiantao wrote:
Seems it lacks device-assignment.[c,h] ?
Xiantao
Hmm, here is the version with the files.
From cd82862ef7493afd3431e538b85adb9771f94da6 Mon Sep 17 00:00:00 2001
From: Amit Shah [EMAIL PROTECTED]
Date: Tue, 16 Sep 2008 23:09:23 +0530
Subject: [PATCH] KVM/userspace: Support for assigning PCI devices to guests
[This still doesn't include some fixes to review comments.
I'm posting this just so that people can use this to test
or base their work off the latest patch.]
From: Or Sagi [EMAIL PROTECTED]
From: Nir Peleg [EMAIL PROTECTED]
From: Amit Shah [EMAIL PROTECTED]
From: Ben-Ami Yassour [EMAIL PROTECTED]
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
With this patch, we can assign a device on the host machine to a
guest.
A new command-line option, -pcidevice is added.
For example, to invoke it for a device sitting at PCI bus:dev.fn
04:08.0 with host IRQ 18, use this:
-pcidevice host=04:08.0
The host driver for the device, if any, is to be removed before
assigning the device.
This works only with the in-kernel irqchip method; to use the
userspace irqchip, a kernel module (irqhook) and some extra changes
are needed.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 14 +
libkvm/libkvm.h | 27 ++
qemu/Makefile.target|1 +
qemu/hw/device-assignment.c | 605
+++
qemu/hw/device-assignment.h | 92 +++
qemu/hw/isa.h |2 +
qemu/hw/pc.c|9 +
qemu/hw/pci.c | 12 +
qemu/hw/pci.h |1 +
qemu/hw/piix_pci.c | 19 ++
qemu/qemu-kvm-x86.c |3 +
qemu/vl.c | 18 ++
12 files changed, 803 insertions(+), 0 deletions(-)
create mode 100644 qemu/hw/device-assignment.c
create mode 100644 qemu/hw/device-assignment.h
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index a8cca15..6157f75 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -53,6 +53,20 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
}
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_PCI_DEVICE, assigned_dev);
+}
+
+int kvm_assign_irq(kvm_context_t kvm,
+ struct kvm_assigned_irq *assigned_irq)
+{
+ return ioctl(kvm-vm_fd, KVM_ASSIGN_IRQ, assigned_irq);
+}
+#endif
+
int kvm_create_pit(kvm_context_t kvm)
{
#ifdef KVM_CAP_PIT
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 79dd769..edf8e9e 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -658,4 +658,31 @@ int kvm_s390_interrupt(kvm_context_t kvm, int slot,
int kvm_s390_set_initial_psw(kvm_context_t kvm, int slot, psw_t psw);
int kvm_s390_store_status(kvm_context_t kvm, int slot, unsigned long addr);
#endif
+
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+/*!
+ * \brief Notifies host kernel aboud a PCI device assigned to guest
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the physical PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_dev Parameters, like bus, devfn number, etc
+ */
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev);
+
+/*!
+ * \brief Notifies host kernel about changes to a irq assignment
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the irq for an assigned physical
+ * PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_irq Parameters, like dev id, host irq, guest irq, etc
+ */
+int kvm_assign_irq(kvm_context_t kvm,
+ struct kvm_assigned_irq *assigned_irq);
+#endif
#endif
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 89814fd..958c33b 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -611,6 +611,7 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o
+OBJS+= device-assignment.o
ifeq ($(USE_KVM_PIT), 1)
OBJS+= i8254-kvm.o
endif
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
new file mode 100644
index 000..d32bbb4
--- /dev/null
+++ b/qemu/hw/device-assignment.c
@@ -0,0 +1,605 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A
[PATCH 3/6] kvmppc: rewrite guest code - sprg0-3
From: Christian Ehrhardt [EMAIL PROTECTED]
This patch adds the functionality of rewriting guest code using the magic page
mechanism. If a paravirtual guest memory (magic page) is registered the host
rewrites trapping emulations instead of emulating them. This only works with
instructions that can be rewritten with one instruction.
On registration of the paravirtual memory the values have to be synced so that
the old emulated values can be found in the magic page now and are ready to be
accessed by the guest.
For speed optimization the rewriting is done only if normal emulation set a
rewritable flag, saving unneccesary calls and checks for every emulation. On the
other hand this implies that the normal emulation was done with out of sync
(non-pv) values. Therefor a second emulation based on pv values is called
prior to the instruction being rewritten. This simplifies the frequent path of
normal instruction emulation by increasing the path when an instruction is
rewritten which is only executed once per rewritable instruction in the guest
code.
The rewriting of guest code is guest visible (the guest already agrees on this
by registering a magic page) and is driven by the program interrupts usually
used to emulate these instructions in the hypervisor.
This patch replaces m[ft]spr SPRG[0-3] instructions with stw (write) and lwz
(read) instructions.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
arch/powerpc/kvm/booke_guest.c | 14 ++
arch/powerpc/kvm/emulate.c | 279 +++--
include/asm-powerpc/kvm_para.h | 25 +++
3 files changed, 310 insertions(+), 8 deletions(-)
[diff]
diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -544,6 +544,13 @@
for (i = 0; i ARRAY_SIZE(regs-gpr); i++)
regs-gpr[i] = vcpu-arch.gpr[i];
+ if (kvmppc_has_pvmem(vcpu)) {
+ regs-sprg0 = kvmppc_get_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG0);
+ regs-sprg1 = kvmppc_get_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG1);
+ regs-sprg2 = kvmppc_get_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG2);
+ regs-sprg3 = kvmppc_get_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG3);
+ }
+
return 0;
}
@@ -569,6 +576,13 @@
for (i = 0; i ARRAY_SIZE(vcpu-arch.gpr); i++)
vcpu-arch.gpr[i] = regs-gpr[i];
+
+ if (kvmppc_has_pvmem(vcpu)) {
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG0, regs-sprg0);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG1, regs-sprg1);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG2, regs-sprg2);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG3, regs-sprg3);
+ }
return 0;
}
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -29,6 +29,7 @@
#include asm/dcr-regs.h
#include asm/time.h
#include asm/byteorder.h
+#include asm/system.h
#include asm/kvm_ppc.h
#include 44x_tlb.h
@@ -87,6 +88,37 @@
static inline unsigned int get_d(u32 inst)
{
return inst 0x;
+}
+
+static inline void set_op(u32 op, u32 *inst)
+{
+ *inst |= ((op 0x3f) 26);
+ return;
+}
+
+static inline void set_ra(u32 ra, u32 *inst)
+{
+ *inst |= ((ra 0x1f) 16);
+ return;
+}
+
+static inline void set_rs(u32 rs, u32 *inst)
+{
+ *inst |= ((rs 0x1f) 21);
+ return;
+}
+
+static inline void set_rt(u32 rt, u32 *inst)
+{
+ *inst |= ((rt 0x1f) 21);
+ return;
+}
+
+static inline void set_d(s16 d, u32 *inst)
+{
+ /* mask in last 16 signed bits */
+ *inst |= ((u32)d 0x);
+ return;
}
static int tlbe_is_host_safe(const struct kvm_vcpu *vcpu,
@@ -212,11 +244,25 @@
switch (vcpu-arch.gpr[11]) {
case KVM_HCALL_RESERVE_MAGICPAGE:
+ /* FIXME assert : we don't support this on smp guests */
+
vcpu-arch.pvmem_gvaddr = vcpu-arch.gpr[3];
vcpu-arch.pvmem_gpaddr = vcpu-arch.gpr[4];
pvmem_page = gfn_to_page(vcpu-kvm,
vcpu-arch.pvmem_gpaddr KVM_PPCPV_MAGIC_PAGE_SHIFT);
vcpu-arch.pvmem = kmap(pvmem_page);
+
+ /* on enablement of pvmem support we need to sync all values
+* into the pvmem area to be able so correcty fulfill read
+* acesses that might occur prior to writes */
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG0,
+ vcpu-arch.sprg0);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG1,
+ vcpu-arch.sprg1);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG2,
+ vcpu-arch.sprg2);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_SPRG3,
+
[PATCH 5/6] kvmppc: rewrite guest code - mfmsr
From: Christian Ehrhardt [EMAIL PROTECTED]
This adds another guest code rewrite support replacing the mfmsr instructions
using the magic page mechanism.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
arch/powerpc/kvm/emulate.c | 20 +++-
include/asm-powerpc/kvm_para.h |1 +
include/asm-powerpc/kvm_ppc.h |3 +++
3 files changed, 23 insertions(+), 1 deletion(-)
[diff]
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -279,6 +279,8 @@
vcpu-arch.dear);
kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_ESR,
vcpu-arch.esr);
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_MSR,
+ vcpu-arch.msr);
break;
default:
printk(KERN_ERR unknown hypercall %d\n, vcpu-arch.gpr[11]);
@@ -304,6 +306,10 @@
switch (get_op(inst)) {
case 31:
switch (get_xop(inst)) {
+ case 83: /* mfmsr */
+ rw = KVM_PPCPV_PVMEM_READ;
+ offset = KVM_PPCPV_OFFSET_MSR;
+ break;
case 339: /* mfspr */
sprn = get_sprn(inst);
rw = KVM_PPCPV_PVMEM_READ;
@@ -445,6 +451,11 @@
switch (get_op(inst)) {
case 31:
switch (get_xop(inst)) {
+ case 83:/* mfmsr */
+ rt = get_rt(inst);
+ vcpu-arch.gpr[rt] = kvmppc_get_pvreg(vcpu,
+ KVM_PPCPV_OFFSET_MSR);
+ break;
case 339: /* mfspr */
sprn = get_sprn(inst);
rt = get_rt(inst);
@@ -602,6 +613,7 @@
case 83:/* mfmsr */
rt = get_rt(inst);
vcpu-arch.gpr[rt] = vcpu-arch.msr;
+ rewritable = 1;
break;
case 87:/* lbzx */
@@ -613,6 +625,9 @@
rs = get_rs(inst);
vcpu-arch.msr = (vcpu-arch.msr ~MSR_EE)
| (vcpu-arch.gpr[rs] MSR_EE);
+ if (kvmppc_has_pvmem(vcpu))
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_MSR,
+ vcpu-arch.msr);
break;
case 146: /* mtmsr */
@@ -629,7 +644,10 @@
case 163: /* wrteei */
vcpu-arch.msr = (vcpu-arch.msr ~MSR_EE)
-| (inst MSR_EE);
+ | (inst MSR_EE);
+ if (kvmppc_has_pvmem(vcpu))
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_MSR,
+ vcpu-arch.msr);
break;
case 215: /* stbx */
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -48,6 +48,7 @@
#define KVM_PPCPV_OFFSET_SRR1 0x14
#define KVM_PPCPV_OFFSET_DEAR 0x18
#define KVM_PPCPV_OFFSET_ESR 0x1C
+#define KVM_PPCPV_OFFSET_MSR 0x20
static inline int kvm_para_available(void)
{
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -28,6 +28,7 @@
#include linux/types.h
#include linux/kvm_types.h
#include linux/kvm_host.h
+#include linux/kvm_para.h
struct kvm_tlb {
struct tlbe guest_tlb[PPC44x_TLB_SIZE];
@@ -88,6 +89,8 @@
kvmppc_mmu_priv_switch(vcpu, new_msr MSR_PR);
vcpu-arch.msr = new_msr;
+ if (kvmppc_has_pvmem(vcpu))
+ kvmppc_set_pvreg(vcpu, KVM_PPCPV_OFFSET_MSR, vcpu-arch.msr);
if (vcpu-arch.msr MSR_WE)
kvm_vcpu_block(vcpu);
--
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 0/3] kvm-userspace: kvmppc: fix build for ppc
From: Christian Ehrhardt [EMAIL PROTECTED] 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 ppc. [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
