Re: [kvm-devel] [ANNOUNCE] kvm-56 release
On Thu, 2007-12-13 at 22:50 +0100, Farkas Levente wrote: Izik Eidus wrote: Farkas Levente wrote: Avi Kivity wrote: This restores live migration support which has been broken for a couple of releases. Also, if you had Java problems please test kvm-56, as it has some nx related permission fixes. unfortunately 32bit centos guest still not be able to boot on 64bit host. Farkas, you cannot boot the guest with single cpu? i am working now on a fix for the smp problem with RHEL 5 32bits, but it always work for me when i try to boot it with single cpu (i tried it on servel computers) sorry i forget to mention the boot only hangs with smp. can you please try to convert the image to vmdk and run it with -smp 2 -no-kvm-irqchip and tell me what happen? - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] aluben-o
Penetrate that ass with your new improved tool! http://laircs.com/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-56 release
On Thu, Dec 13, 2007 at 03:32:46PM +0200, Avi Kivity wrote: Notes: If you use the modules bundled with kvm-56, you can use any version of Linux from 2.6.9 upwards. the external module (once patched) will only be able to build against 2.6.17 upwards because the in-kernel PIC/IOAPIC/LAPIC requires hrtimers and that functionality was only made public to external modules during the stabilization of 2.6.17 as seen by : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d16b76421f0b3216012ee2d7819355e1cb847e5 there are obviously 3 possible fixes : 1) rewrite the in-kernel PIC/IOAPIC/LAPIC not to use hrtimers (not worthy) 2) replicate the functionality needed in the compatibility header or with the use of a helper (not that simple) 3) disable the functionality and ifdef the code for kernel 2.6.17 (preferred) but before, I would like to ask: is 2.6.9 upwards support really needed?, the only reason why I would suspect that 2.6.9 was recommended was because of RHEL4 but there is no kvm package available for it from Red Hat or in EPEL and Full Support is due May 15, 2008 so there might not be one ever, specially considering that Red Hat is focused on RHEL 5 Host for virtualization support as can be seen by : http://www.redhat.com/rhel/virtualization/ other Linux distributions that are still under support will be affected as well (mainly because they are corporate linux focused and with longer supported timelines than community oriented distributions) but AFAIK they don't have yet a kvm package (and might never had one) : * Ubuntu Dapper 6.06.1 LTS (2.6.15) * SuSE Linux 10.1 (2.6.16) * Mandriva Corporate 4 (2.6.12) of course ALL community oriented distributions (fedora, ubuntu, gentoo) which are currently packaging kvm are ok and won't be affected by a 2.6.17 upwards requirement. Carlo PS. shouldn't the 2.6.9 or higher requirement be in this page? http://kvm.qumranet.com/kvmwiki/Downloads - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] question on #UD emulation
Avi/Anthony: Following commit added #UD trap in KVM and do emulation in KVM. It is good to avoid the mis hypercall instruction issue, but I am not sure if it will have any serious side effect. I am blind to AMD instruction, I assume, for example, AMD 3D now instruction may use different binary and thus invalid_ops in Intel platform. If an application with 3D now instructions is executed in Intel platform, now KVM get #UD and may do emulation inside, will that cause problem rather then we inject #UD to guest? If this suspicion is true, then probably we need to do something more to this commitment, i.e. to emulate cross-architecturally VMCALL instruction only for this purpose. BTW, do we need to support live migrating an AMD VM to Intel platform or vice versa? thx,eddie commit 8db6e3d54971e76019b02a6ad860c9df35218dfc Date: Mon Sep 17 14:57:50 2007 -0500 KVM: Refactor hypercall infrastructure (v3) This patch refactors the current hypercall infrastructure to better support live migration and SMP. It eliminates the hypercall page by trapping the UD exception that would occur if you used the wrong hypercall instruction for the underlying architecture and replacing it with the right one lazily. A fall-out of this patch is that the unhandled hypercalls no longer trap to userspace. There is very little reason though to use a hypercall to communicate with userspace as PIO or MMIO can be used. There is no code in tree that uses userspace hypercalls. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ kvm-Bugs-1850911 ] qemu-img -c not working
SourceForge.net wrote: Bugs item #1850911, was opened at 2007-12-14 12:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1850911group_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: Olivier Paquet (euzeka) Assigned to: Nobody/Anonymous (nobody) Summary: qemu-img -c not working Initial Comment: With kvm-56, running: qemu-img convert -c winxp64.img -O qcow2 test.img qemu-img: Alternative compatibility level not supported for this file format -c is for compressed target source image. Naturally, .img file is not compressed. Did you wanted to compress the destination? Anyway qemu is the right place for these type of bugs. Thanks, Dor. Looking at the source of qemu-img.c, there is an obvious bug at line 474 (if the usage text is to be trusted): if (flags BLOCK_FLAG_COMPRESS drv != bdrv_vmdk) error(Alternative compatibility level not supported for this file format); This should probably be BLOCK_FLAG_COMPAT6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1850911group_id=180599 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [virtio-net][PATCH] Don't arm tx hrtimer with a constant 500us each transmit
Cam Macdonell wrote: Dor Laor wrote: Christian Borntraeger wrote: Am Mittwoch, 12. Dezember 2007 schrieb Dor Laor: Christian Borntraeger wrote: Am Mittwoch, 12. Dezember 2007 schrieb Dor Laor: --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -406,10 +405,10 @@ again: Hmm, while I agree in general with the patch, I fail to find the proper version of virtio_net where this patch applies. I tried kvm.git and linux-2.6.git from kernel.org. Can you give me a pointer to the repository where you work on virtio? Sorry for that, I added some debug prints of my one. Here it is: *git clone git*://kvm.*qumranet*.com/home/*dor*/src/linux-2.6-nv use branch 'virtio'. Hi Dor, Which userspace repo is usable with the above repo? Thanks, Cam git://kvm.qumranet.com/home/dor/src/kvm-nv use branch Regards, Dor. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] question on #UD emulation
Dong, Eddie wrote: Avi/Anthony: Following commit added #UD trap in KVM and do emulation in KVM. It is good to avoid the mis hypercall instruction issue, but I am not sure if it will have any serious side effect. I am blind to AMD instruction, I assume, for example, AMD 3D now instruction may use different binary and thus invalid_ops in Intel platform. If an application with 3D now instructions is executed in Intel platform, now KVM get #UD and may do emulation inside, will that cause problem rather then we inject #UD to guest? If this suspicion is true, then probably we need to do something more to this commitment, i.e. to emulate cross-architecturally VMCALL instruction only for this purpose. Since we don't emulate 3Dnow instructions, a #UD will be injected instead. The plan for having mixed vendor migration is to disable such extensions in cpuid, so the guest won't even try to execute them. In other words, the cpuid in a virtualization farm will be set to the greatest common subset of cpu features. BTW, do we need to support live migrating an AMD VM to Intel platform or vice versa Yes, it allows users to buy the machines with the best cost/performance ratio, rather than continue to buy machines from the same vendor all the time. -- error compiling committee.c: too many arguments to function - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-56 release
Carlo Marcelo Arenas Belon wrote: On Thu, Dec 13, 2007 at 03:32:46PM +0200, Avi Kivity wrote: Notes: If you use the modules bundled with kvm-56, you can use any version of Linux from 2.6.9 upwards. the external module (once patched) will only be able to build against 2.6.17 upwards because the in-kernel PIC/IOAPIC/LAPIC requires hrtimers and that functionality was only made public to external modules during the stabilization of 2.6.17 as seen by : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d16b76421f0b3216012ee2d7819355e1cb847e5 there are obviously 3 possible fixes : 1) rewrite the in-kernel PIC/IOAPIC/LAPIC not to use hrtimers (not worthy) 2) replicate the functionality needed in the compatibility header or with the use of a helper (not that simple) 3) disable the functionality and ifdef the code for kernel 2.6.17 (preferred) but before, I would like to ask: is 2.6.9 upwards support really needed?, I imagine you're right, since there are few complaints. Most people have migrated to RHEL 5 or its equivalents. the only reason why I would suspect that 2.6.9 was recommended was because of RHEL4 Yes. -- error compiling committee.c: too many arguments to function - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio_net and SMP guests
Christian Borntraeger wrote: Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU:2Not tainted Process swapper (pid: 0, task: 0f83e038, ksp: 0f877d70) Krnl PSW : 070400018000 0045df2a (vring_restart+0x5a/0x70) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3 Krnl GPRS: c0a80101 0eb35000 10005800 0045ded0 192f 0eb21000 0eb21000 000e 0eb21900 0eb21920 0f867cb8 07d9b058 0010 0045c06a 0f867cb8 Krnl Code: 0045df1e: e3b0b074 lg %r11,112(%r11) 0045df24: 07fe bcr 15,%r14 0045df26: a7f40001 brc 15,45df28 0045df2a: a7f4ffe1 brc 15,45deec 0045df2e: e3102034 lg %r1,48(%r2) 0045df34: a748 lhi %r4,0 0045df38: 96011001 oi 1(%r1),1 0045df3c: a7f4ffef brc 15,45df1a Call Trace: ([0045c016] virtnet_poll+0x96/0x42c) [0048cda2] net_rx_action+0xca/0x150 [00137f7a] __do_softirq+0x9e/0x130 [001105d6] do_softirq+0xae/0xb4 [00138182] irq_exit+0x96/0x9c [0010d710] do_extint+0xcc/0xf8 [001135d0] ext_no_vtime+0x16/0x1a [0010a57e] cpu_idle+0x216/0x238 I think there is a valid code path, triggering this bug: CPU1CPU2 --- --- - virtnet_poll found no more packets on queue - netif_rx_complete allow poll to be called - vq_ops-restart is called - vq Interrupts are enabled .new packets arrive vcpu is scheduled away . - interrupt is delivered . - poll is called . - poll work is done . - netif_rx_complete . - vq_ops-restart is called . - check if vq interrupts are . enable -- BUG I didn't understand how its possible: vcpu is scheduled away . - interrupt is delivered -vring_interrupt is called - - skb_recv_done callback return false - vq-vring.avail-flags |= VRING_AVAIL_F_NO_INTERRUPT; So when the restart callback will be called the BUG_ON(!(vq-vring.avail-flags VRING_AVAIL_F_NO_INTERRUPT)); will not be issued. . - poll is called . - poll work is done . - netif_rx_complete . - vq_ops-restart is called . - check if vq interrupts are . enable -- BUG The first idea was to remove this check? (See patch below). I am not sure if the proper fix also requires to change vring.avail-flags to be only changed by atomic bitops. Any ideas, comments? As for now no harm can be done since it is only used in two place: 1. vring_restart inside a napi poll calback which is protected by napi poll lock 2. vring_interrupt in the interrupt handler. While only the VRING_AVAIL_F_NO_INTERRUPT bit is touched there is no possible harm, once we'll use more bits it might be an issue. So Maybe we should use atomics. Signed-off-by: Christian Borntraeger [EMAIL PROTECTED] CC: Anthony Liguori [EMAIL PROTECTED] CC: Dor Laor [EMAIL PROTECTED] CC: Rusty Russell [EMAIL PROTECTED] --- drivers/virtio/virtio_ring.c |2 -- 1 file changed, 2 deletions(-) Index: kvm/drivers/virtio/virtio_ring.c === --- kvm.orig/drivers/virtio/virtio_ring.c +++ kvm/drivers/virtio/virtio_ring.c @@ -225,8 +225,6 @@ static bool vring_restart(struct virtque struct vring_virtqueue *vq = to_vvq(_vq); START_USE(vq); - BUG_ON(!(vq-vring.avail-flags VRING_AVAIL_F_NO_INTERRUPT)); - /* We optimistically turn back on interrupts, then check if there was * more to do. */
Re: [kvm-devel] [PATCH] external module: include apicdef.h for kernel 2.6.21
Carlo Marcelo Arenas Belon wrote: The following patch fixes building the kvm module for kernels older than 2.6.21 and which were missing an include to asm/apicdef.h in asm/io_apic.h resulting in the following error : include/asm/io_apic.h:61: error: 'MAX_IO_APICS' undeclared here (not in a function) Do all kernels/arches have this file? maybe a #ifndef/#define/#endif sequence is better here. -- error compiling committee.c: too many arguments to function - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1851814 ] Qemu Crashes with evidence of memory corruption
Bugs item #1851814, was opened at 2007-12-16 14:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1851814group_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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: Qemu Crashes with evidence of memory corruption Initial Comment: Qumranet's Automated GuestWizard testing reveals, that in some cases Qemu double frees memory and crashes. Tested with both Qemu-CVS-2007-12-10 and KVM-56 (both Userspace-only and kernelspace/userspace combo). Error message: == *** glibc detected *** /usr/local/bin/qemu-system-x86_64: double free or corruption (fasttop): 0x02b6cb10 *** === Backtrace: = /lib64/libc.so.6[0x3dd0270412] /lib64/libc.so.6(cfree+0x8c)[0x3dd0273b1c] /usr/local/bin/qemu-system-x86_64[0x4116c1] /usr/local/bin/qemu-system-x86_64[0x41403d] /usr/local/bin/qemu-system-x86_64[0x40889e] /usr/local/bin/qemu-system-x86_64[0x40db72] /usr/local/bin/qemu-system-x86_64[0x48cf15] /usr/local/bin/qemu-system-x86_64[0x48cf9b] /usr/local/bin/qemu-system-x86_64[0x48d381] /usr/local/bin/qemu-system-x86_64[0x40dd27] /usr/local/bin/qemu-system-x86_64[0x40fd03] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3dd021daa4] /usr/local/bin/qemu-system-x86_64[0x4060b9] === Memory map: 0040-0055b000 r-xp fd:00 1961296 /usr/local/bin/qemu-system-x86_64 0075b000-0076f000 rw-p 0015b000 fd:00 1961296 /usr/local/bin/qemu-system-x86_64 0076f000-01a3a000 rw-p 0076f000 00:00 0 01a3a000-02a3b000 rwxp 01a3a000 00:00 0 02a3b000-02dcb000 rw-p 02a3b000 00:00 0 [heap] 3dcfe0-3dcfe1a000 r-xp fd:00 1267006 /lib64/ld-2.6.so 3dd0019000-3dd001a000 r--p 00019000 fd:00 1267006 /lib64/ld-2.6.so 3dd001a000-3dd001b000 rw-p 0001a000 fd:00 1267006 /lib64/ld-2.6.so 3dd020-3dd0347000 r-xp fd:00 1267007 /lib64/libc-2.6.so 3dd0347000-3dd0546000 ---p 00147000 fd:00 1267007 /lib64/libc-2.6.so 3dd0546000-3dd054a000 r--p 00146000 fd:00 1267007 /lib64/libc-2.6.so 3dd054a000-3dd054b000 rw-p 0014a000 fd:00 1267007 /lib64/libc-2.6.so 3dd054b000-3dd055 rw-p 3dd054b000 00:00 0 3dd060-3dd0602000 r-xp fd:00 1267010 /lib64/libdl-2.6.so 3dd0602000-3dd0802000 ---p 2000 fd:00 1267010 /lib64/libdl-2.6.so 3dd0802000-3dd0803000 r--p 2000 fd:00 1267010 /lib64/libdl-2.6.so 3dd0803000-3dd0804000 rw-p 3000 fd:00 1267010 /lib64/libdl-2.6.so 3dd0a0-3dd0a82000 r-xp fd:00 1267009 /lib64/libm-2.6.so 3dd0a82000-3dd0c81000 ---p 00082000 fd:00 1267009 /lib64/libm-2.6.so 3dd0c81000-3dd0c82000 r--p 00081000 fd:00 1267009 /lib64/libm-2.6.so 3dd0c82000-3dd0c83000 rw-p 00082000 fd:00 1267009 /lib64/libm-2.6.so 3dd0e0-3dd0e14000 r-xp fd:00 1267008 /lib64/libz.so.1.2.3 3dd0e14000-3dd1013000 ---p 00014000 fd:00 1267008 /lib64/libz.so.1.2.3 3dd1013000-3dd1014000 rw-p 00013000 fd:00 1267008 /lib64/libz.so.1.2.3 3dd120-3dd1215000 r-xp fd:00 1267012 /lib64/libpthread-2.6.so 3dd1215000-3dd1414000 ---p 00015000 fd:00 1267012 /lib64/libpthread-2.6.so 3dd1414000-3dd1415000 r--p 00014000 fd:00 1267012 /lib64/libpthread-2.6.so 3dd1415000-3dd1416000 rw-p 00015000 fd:00 1267012 /lib64/libpthread-2.6.so 3dd1416000-3dd141a000 rw-p 3dd1416000 00:00 0 3dd160-3dd1704000 r-xp fd:00 1953728 /usr/lib64/libX11.so.6.2.0 3dd1704000-3dd1904000 ---p 00104000 fd:00 1953728 /usr/lib64/libX11.so.6.2.0 3dd1904000-3dd190b000 rw-p 00104000 fd:00 1953728 /usr/lib64/libX11.so.6.2.0 3dd1a0-3dd1a02000 r-xp fd:00 1952614 /usr/lib64/libXau.so.6.0.0 3dd1a02000-3dd1c01000 ---p 2000 fd:00 1952614 /usr/lib64/libXau.so.6.0.0 3dd1c01000-3dd1c02000 rw-p 1000 fd:00 1952614 /usr/lib64/libXau.so.6.0.0 3dd1e0-3dd1e05000 r-xp fd:00 1953727 /usr/lib64/libXdmcp.so.6.0.0 3dd1e05000-3dd2004000 ---p 5000 fd:00 1953727
Re: [kvm-devel] question on #UD emulation
On Sun, Dec 16, 2007 at 01:32:40PM +0200, Avi Kivity wrote: Dong, Eddie wrote: BTW, do we need to support live migrating an AMD VM to Intel platform or vice versa Yes, it allows users to buy the machines with the best cost/performance ratio, rather than continue to buy machines from the same vendor all the time. I don't agree with this. A user can still buy machines from both vendors and migrate offline it he wants to. In general I think that allowing live migration between Intel and AMD hosts is not a good idea because you limit the guest to the subset of the CPU features available on both platforms. This disallows many optimizations and costs performance for the guest. Take the problem Dor mentioned this week about the performance impact of the gettimeofday() syscall causing many cpuid guest exits. If we had not to support migration between AMD and Intel we could simply propagate FEATURE_RDTSCP to an guest on AMD an SYNC_RDTSC on Intel platforms. The Linux get_cycles_sync() function would then no longer execute CPUID. This is only one example, I found some more during my work on KVM. 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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] question on #UD emulation
Joerg Roedel wrote: On Sun, Dec 16, 2007 at 01:32:40PM +0200, Avi Kivity wrote: Dong, Eddie wrote: BTW, do we need to support live migrating an AMD VM to Intel platform or vice versa Yes, it allows users to buy the machines with the best cost/performance ratio, rather than continue to buy machines from the same vendor all the time. I don't agree with this. A user can still buy machines from both vendors and migrate offline it he wants to. In general I think that allowing live migration between Intel and AMD hosts is not a good idea because you limit the guest to the subset of the CPU features available on both platforms. This disallows many optimizations and costs performance for the guest. Having the option to live migrate between various hosts is a powerful feature. Of course it costs some performance penalty but it might not be relevant for the user work load. By having cmd line parameters to control the cpuid and cpu type one can dynamically calculate the lowest common denominator and to run his virtual machines using it. One can always pass -cpu=host to have maximum performance. For users who like to live migrate between Amd-Intel we'll use one of cpu types for both. Regards, Dor Take the problem Dor mentioned this week about the performance impact of the gettimeofday() syscall causing many cpuid guest exits. If we had not to support migration between AMD and Intel we could simply propagate FEATURE_RDTSCP to an guest on AMD an SYNC_RDTSC on Intel platforms. The Linux get_cycles_sync() function would then no longer execute CPUID. This is only one example, I found some more during my work on KVM. 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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] 代理
广州市广程贸易有限公司 致!尊敬的客户您好! 本公司是一家综合性实力雄厚定额纳税企业，与全国各地区众多公司有业务往来，可长期代理全国各地 的各种类发票等业务，（包括增值税发票、国税、地税、普通发票）可供网上查询或税务局验证后付款。谢谢 （如有打扰之处敬请谅解） 联系人: 张国锋 电话/Tel: 13580523256 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] question on #UD emulation
Since we don't emulate 3Dnow instructions, a #UD will be injected instead. OK, how many architecture specific instructiosn are emulated now? Or what is planed to be implemented? If no, then adding those emulation in KVM just means dead code. thx,eddie - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] question on #UD emulation
A little bit suspicion for the usage model too :( The CPUID feature list can't be changed dynamically, so I doutb if a real user will give up performance at beginning when he/she starts the guest for maybe future migration cross host platform. A VT or SVM enabled machine usually has many features which doesn't exist in the common feature list for both Intel AMD, such as MMX/SSE2/SSE3. So the performance penalty could be big. Eddie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dor Laor Sent: 2007年12月16日 20:50 To: Joerg Roedel Cc: kvm-devel; Avi Kivity Subject: Re: [kvm-devel] question on #UD emulation Joerg Roedel wrote: On Sun, Dec 16, 2007 at 01:32:40PM +0200, Avi Kivity wrote: Dong, Eddie wrote: BTW, do we need to support live migrating an AMD VM to Intel platform or vice versa Yes, it allows users to buy the machines with the best cost/performance ratio, rather than continue to buy machines from the same vendor all the time. I don't agree with this. A user can still buy machines from both vendors and migrate offline it he wants to. In general I think that allowing live migration between Intel and AMD hosts is not a good idea because you limit the guest to the subset of the CPU features available on both platforms. This disallows many optimizations and costs performance for the guest. Having the option to live migrate between various hosts is a powerful feature. Of course it costs some performance penalty but it might not be relevant for the user work load. By having cmd line parameters to control the cpuid and cpu type one can dynamically calculate the lowest common denominator and to run his virtual machines using it. One can always pass -cpu=host to have maximum performance. For users who like to live migrate between Amd-Intel we'll use one of cpu types for both. Regards, Dor Take the problem Dor mentioned this week about the performance impact of the gettimeofday() syscall causing many cpuid guest exits. If we had not to support migration between AMD and Intel we could simply propagate FEATURE_RDTSCP to an guest on AMD an SYNC_RDTSC on Intel platforms. The Linux get_cycles_sync() function would then no longer execute CPUID. This is only one example, I found some more during my work on KVM. 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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] question on #UD emulation
Dong, Eddie wrote: A little bit suspicion for the usage model too :( The CPUID feature list can't be changed dynamically, so I doutb if a real user will give up performance at beginning when he/she starts the guest for maybe future migration cross host platform. A VT or SVM enabled machine usually has many features which doesn't exist in the common feature list for both Intel AMD, such as MMX/SSE2/SSE3. So the performance penalty could be big. mmx/sse2/sse3 are actually common across intel/amd; the performance difference should be minor (well, depending on the workload). -- error compiling committee.c: too many arguments to function - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] question on #UD emulation
Dong, Eddie wrote: Since we don't emulate 3Dnow instructions, a #UD will be injected instead. OK, how many architecture specific instructiosn are emulated now? Just vmcall/vmmcall (which is emulated once, then patched). Or what is planed to be implemented? If no, then adding those emulation in KVM just means dead code. sysenter/sysexit (which aren't implemented in amd compatibility mode) and syscall/sysret (which aren't implemented in intel compatibility mode). Both are only used for 32-bit userspace on 64-bit guests, so they aren't too critical. -- error compiling committee.c: too many arguments to function - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Make ioapic.c independent of x86 header files
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Sun, 16 Dec 2007 23:41:50 +0800
Subject: [PATCH] kvm: Split irq.h into two parts, and make ioapic
independent of
X86 header files.
This patch splits irq.h into two parts, and make ioapic independent of
X86 header files.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
arch/x86/kvm/ioapic.h | 98
+
arch/x86/kvm/irq.h| 89
+---
2 files changed, 100 insertions(+), 87 deletions(-)
create mode 100644 arch/x86/kvm/ioapic.h
diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
new file mode 100644
index 000..5a01013
--- /dev/null
+++ b/arch/x86/kvm/ioapic.h
@@ -0,0 +1,98 @@
+#ifndef __KVM_IO_APIC_H
+#define __KVM_IO_APIC_H
+#include linux/kvm_host.h
+#include iodev.h
+
+struct kvm;
+struct kvm_vcpu;
+
+#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
+#define IOAPIC_VERSION_ID 0x11 /* IOAPIC version */
+#define IOAPIC_EDGE_TRIG 0
+#define IOAPIC_LEVEL_TRIG 1
+
+#define IOAPIC_DEFAULT_BASE_ADDRESS 0xfec0
+#define IOAPIC_MEM_LENGTH0x100
+
+/* Direct registers. */
+#define IOAPIC_REG_SELECT 0x00
+#define IOAPIC_REG_WINDOW 0x10
+#define IOAPIC_REG_EOI 0x40/* IA64 IOSAPIC only */
+
+/* Indirect registers. */
+#define IOAPIC_REG_APIC_ID 0x00/* x86 IOAPIC only */
+#define IOAPIC_REG_VERSION 0x01
+#define IOAPIC_REG_ARB_ID 0x02/* x86 IOAPIC only */
+
+/*ioapic delivery mode*/
+#defineIOAPIC_FIXED0x0
+#defineIOAPIC_LOWEST_PRIORITY 0x1
+#defineIOAPIC_PMI 0x2
+#defineIOAPIC_NMI 0x4
+#defineIOAPIC_INIT 0x5
+#defineIOAPIC_EXTINT 0x7
+
+struct kvm_ioapic {
+ u64 base_address;
+ u32 ioregsel;
+ u32 id;
+ u32 irr;
+ u32 pad;
+ union ioapic_redir_entry {
+ u64 bits;
+ struct {
+ u8 vector;
+ u8 delivery_mode:3;
+ u8 dest_mode:1;
+ u8 delivery_status:1;
+ u8 polarity:1;
+ u8 remote_irr:1;
+ u8 trig_mode:1;
+ u8 mask:1;
+ u8 reserve:7;
+ u8 reserved[4];
+ u8 dest_id;
+ } fields;
+ } redirtbl[IOAPIC_NUM_PINS];
+ struct kvm_io_device dev;
+ struct kvm *kvm;
+};
+
+#ifdef DEBUG
+#define ASSERT(x)
\
+do {
\
+ if (!(x)) {
\
+ printk(KERN_EMERG assertion failed %s: %d: %s\n,
\
+ __FILE__, __LINE__, #x);
\
+ BUG();
\
+ }
\
+} while (0)
+#else
+#define ASSERT(x) do { } while (0)
+#endif
+
+static inline struct kvm_ioapic *ioapic_irqchip(struct kvm *kvm)
+{
+ return kvm-arch.vioapic;
+}
+
+static inline int irqchip_in_kernel(struct kvm *kvm)
+{
+ return ioapic_irqchip(kvm) != NULL;
+}
+
+void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
+struct kvm_vcpu *kvm_get_lowest_prio_vcpu(struct kvm *kvm, u8 vector,
+ unsigned long bitmap);
+void kvm_ioapic_update_eoi(struct kvm *kvm, int vector);
+int kvm_ioapic_init(struct kvm *kvm);
+void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level);
+void kvm_ioapic_reset(struct kvm_ioapic *ioapic);
+
+int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u16 dest);
+int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8 mda);
+int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig);
+int kvm_create_lapic(struct kvm_vcpu *vcpu);
+void kvm_free_lapic(struct kvm_vcpu *vcpu);
+
+#endif
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 6316638..696c6b3 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -25,7 +25,9 @@
#include linux/mm_types.h
#include linux/hrtimer.h
#include linux/kvm_host.h
+
#include iodev.h
+#include ioapic.h
struct kvm;
struct kvm_vcpu;
@@ -65,58 +67,6 @@ void kvm_pic_set_irq(void *opaque, int irq, int
level);
int kvm_pic_read_irq(struct kvm_pic *s);
void kvm_pic_update_irq(struct kvm_pic *s);
-#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
-#define IOAPIC_VERSION_ID 0x11 /* IOAPIC version */
-#define IOAPIC_EDGE_TRIG 0
-#define IOAPIC_LEVEL_TRIG 1
-
-#define IOAPIC_DEFAULT_BASE_ADDRESS 0xfec0
-#define IOAPIC_MEM_LENGTH0x100
-
-/* Direct registers. */
-#define IOAPIC_REG_SELECT 0x00
-#define IOAPIC_REG_WINDOW 0x10
-#define IOAPIC_REG_EOI 0x40/* IA64 IOSAPIC only */
-
-/* Indirect registers. */
-#define IOAPIC_REG_APIC_ID 0x00/* x86 IOAPIC only */
-#define IOAPIC_REG_VERSION 0x01
-#define IOAPIC_REG_ARB_ID 0x02/* x86 IOAPIC only */
-
-/*ioapic delivery mode*/
-#defineIOAPIC_FIXED0x0
-#defineIOAPIC_LOWEST_PRIORITY 0x1
-#defineIOAPIC_PMI
Re: [kvm-devel] [PATCH] Make ioapic.c independent of x86 header files
Zhang, Xiantao wrote:
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Sun, 16 Dec 2007 23:41:50 +0800
Subject: [PATCH] kvm: Split irq.h into two parts, and make ioapic
independent of
X86 header files.
This patch splits irq.h into two parts, and make ioapic independent of
X86 header files.
2 files changed, 100 insertions(+), 87 deletions(-)
create mode 100644 arch/x86/kvm/ioapic.h
diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
new file mode 100644
index 000..5a01013
--- /dev/null
+++ b/arch/x86/kvm/ioapic.h
@@ -0,0 +1,98 @@
+#ifndef __KVM_IO_APIC_H
+#define __KVM_IO_APIC_H
blank line here
+#include linux/kvm_host.h
+#include iodev.h
+
+}
+
+static inline int irqchip_in_kernel(struct kvm *kvm)
+{
+ return ioapic_irqchip(kvm) != NULL;
+}
This doesn't belong here. Also, the definition is changed -- you should
have noted that.
I think for ia64 you can set irqchip_in_kernel() to return true
unconditionally.
+void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
Doesn't belong here, maybe kvm_host.h.
+struct kvm_vcpu *kvm_get_lowest_prio_vcpu(struct kvm *kvm, u8 vector,
+unsigned long bitmap);
+void kvm_ioapic_update_eoi(struct kvm *kvm, int vector);
+int kvm_ioapic_init(struct kvm *kvm);
+void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level);
+void kvm_ioapic_reset(struct kvm_ioapic *ioapic);
+
+int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u16 dest);
+int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8 mda);
+int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig);
+int kvm_create_lapic(struct kvm_vcpu *vcpu);
+void kvm_free_lapic(struct kvm_vcpu *vcpu);
The non-ioapic functions shouldn't be here.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving ioapic.h and ioapic.c back to common directory
Zhang, Xiantao wrote: common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o) +common-objs += $(addprefix ../../../virt/kvm/, ioapic.o) Just add ioapic.o behind kvm_main.o; it's a list. -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] new user issues
Is there a GUI for managing virtual machine with KVM? I have tried to get kvm working with this tutorial from the command line, http://www.michaeldolan.com/1030#comment-10228 ...but this is the problem I can't get past, I added the user to the kvm group and confirmed it, [EMAIL PROTECTED]:~$ sudo adduser pr kvm The user `pr’ is already a member of `kvm’. Then, with this command, [EMAIL PROTECTED]:~$ kvm -std-vga -m 750 -cdrom /home/pr/kubuntu-7.10-desktop-amd64.iso -boot d gutsy-desktop.img open /dev/kvm: Permission denied Could not initialize KVM, will disable KVM support I can see the Kubuntu install screen in the QEMU/KVM screen but when I try and install I get a “I/O Error Error Reading Boot CD” …next I tried this command, sudo kvm -std-vga -m 750 -cdrom /home/pr/kubuntu-7.10-desktop-amd64.iso -boot d gutsy-desktop.img I just get the “I/O Error Error Reading Boot CD” error in the QEMU/KVM screen, I also tried chmod 777 /dev/kvm, same results as above. (HP Pavillion AMD 64 bit) Any suggestions? Thanks, pr Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] external module: include apicdef.h for kernel 2.6.21
On Sun, Dec 16, 2007 at 01:56:06PM +0200, Avi Kivity wrote: Carlo Marcelo Arenas Belon wrote: The following patch fixes building the kvm module for kernels older than 2.6.21 and which were missing an include to asm/apicdef.h in asm/io_apic.h resulting in the following error : include/asm/io_apic.h:61: error: 'MAX_IO_APICS' undeclared here (not in a function) Do all kernels/arches have this file? apicdef.h has been around since 2.6.12 and was added to io_apic.h for 2.6.21 as can be seen in : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=58a53b246b4aed95f3f93b45828c8d9f26b1cfcb as for arches, it is only available in i386 and x86_64 (and in the merged x86 for 2.6.24) but the same is true for io_apic.h maybe a #ifndef/#define/#endif sequence is better here. for 2.6.21 and 2.6.19 yes, but 2.6.16 needs also FIX_IO_APIC_BASE_0 and __fix_to_virt to build and therefore asm/fixmap.h (which then includes apicdef.h) I agree though that and #if KV/#include/#endif is not good as it doesn't stress the fact that this problem is only visible for CONFIG_SMP=no for old kernels so don't commit this one just yet as it is missing context and is only the first out of 5 patches that I'd been testing for supporting all stable gentoo kernels and that lead to the realization that 2.6.16 wouldn't work as I reported before. Carlo - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] new user issues
On Monday 17 December 2007 03:18:55 Peter O'Reilly wrote: Is there a GUI for managing virtual machine with KVM? I have tried to get kvm working with this tutorial from the command line, http://www.michaeldolan.com/1030#comment-10228 ...but this is the problem I can't get past, I added the user to the kvm group and confirmed it, [EMAIL PROTECTED]:~$ sudo adduser pr kvm The user `pr’ is already a member of `kvm’. Then, with this command, [EMAIL PROTECTED]:~$ kvm -std-vga -m 750 -cdrom /home/pr/kubuntu-7.10-desktop-amd64.iso -boot d gutsy-desktop.img open /dev/kvm: Permission denied You have to log out and log in for this to take effect. sudo kvm -std-vga -m 750 -cdrom /home/pr/kubuntu-7.10-desktop-amd64.iso -boot d gutsy-desktop.img I just get the “I/O Error Error Reading Boot CD” error in the QEMU/KVM screen, add the -hda option before gutsy-desktop.img. Also verify if the hash of the ISO is correct (md5sum / sha1) Amit. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [3/3] kvm: Moving out kvm_vcpu_kick from irq.c
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 14:21:40 +0800
Subject: [PATCH] kvm: Moving out kvm_vcpu_kick from irq.c
Moving kvm_vcpu_kick to x86.c. Since it should be
common for all archs, put its declarations in linux/kvm_host.h
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
arch/x86/kvm/irq.c | 20
arch/x86/kvm/irq.h |2 --
arch/x86/kvm/x86.c | 20
include/linux/kvm_host.h |1 +
4 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 07a09aa..e571475 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -63,26 +63,6 @@ int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
}
EXPORT_SYMBOL_GPL(kvm_cpu_get_interrupt);
-static void vcpu_kick_intr(void *info)
-{
-#ifdef DEBUG
- struct kvm_vcpu *vcpu = (struct kvm_vcpu *)info;
- printk(KERN_DEBUG vcpu_kick_intr %p \n, vcpu);
-#endif
-}
-
-void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
-{
- int ipi_pcpu = vcpu-cpu;
-
- if (waitqueue_active(vcpu-wq)) {
- wake_up_interruptible(vcpu-wq);
- ++vcpu-stat.halt_wakeup;
- }
- if (vcpu-guest_mode)
- smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu,
0, 0);
-}
-
void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu)
{
kvm_inject_apic_timer_irqs(vcpu);
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index c376b5b..53c7f48 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -85,6 +85,4 @@ void kvm_inject_pending_timer_irqs(struct kvm_vcpu
*vcpu);
void kvm_inject_apic_timer_irqs(struct kvm_vcpu *vcpu);
void kvm_migrate_apic_timer(struct kvm_vcpu *vcpu);
-void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
-
#endif
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d905d90..93259e5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3145,3 +3145,23 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
|| vcpu-arch.mp_state == VCPU_MP_STATE_SIPI_RECEIVED;
}
+static void vcpu_kick_intr(void *info)
+{
+#ifdef DEBUG
+ struct kvm_vcpu *vcpu = (struct kvm_vcpu *)info;
+ printk(KERN_DEBUG vcpu_kick_intr %p \n, vcpu);
+#endif
+}
+
+void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
+{
+ int ipi_pcpu = vcpu-cpu;
+
+ if (waitqueue_active(vcpu-wq)) {
+ wake_up_interruptible(vcpu-wq);
+ ++vcpu-stat.halt_wakeup;
+ }
+ if (vcpu-guest_mode)
+ smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu,
0, 0);
+}
+
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a85d5b6..953b50a 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -250,6 +250,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm);
int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
int kvm_cpu_has_interrupt(struct kvm_vcpu *v);
+void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
static inline void kvm_guest_enter(void)
{
--
1.5.1.2
0003-kvm-Moving-out-kvm_vcpu_kick-from-irq.c.patch
Description: 0003-kvm-Moving-out-kvm_vcpu_kick-from-irq.c.patch
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] [0/3] Make ioapic.c independent of x86 header files V2
According to Avi's comments, Updated the patches.
[1/3] Create ioapic.h and lapic.h to hold their declarations.
[2/3] Moving ioapic{.h,.c} back to common directory.
[3/3] Moving out kvm_vcpu_kick from irq.c
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [1/3] Create ioapic.h and lapic.h to hold their declarations
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 13:59:56 +0800
Subject: [PATCH] kvm: Create ioapic.h and lapic.h to hold their own
declarations.
It helps to make ioapic independent of X86 header files.
Two files ioapic.h and lapic.h are created.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
arch/x86/kvm/ioapic.c |5 ++-
arch/x86/kvm/ioapic.h | 95
arch/x86/kvm/irq.h| 115
++--
arch/x86/kvm/lapic.h | 44 +++
4 files changed, 148 insertions(+), 111 deletions(-)
create mode 100644 arch/x86/kvm/ioapic.h
create mode 100644 arch/x86/kvm/lapic.h
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 72f12f7..40cd53e 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -36,7 +36,10 @@
#include asm/processor.h
#include asm/page.h
#include asm/current.h
-#include irq.h
+
+#include ioapic.h
+#include lapic.h
+
#if 0
#define ioapic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg)
#else
diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
new file mode 100644
index 000..7f16675
--- /dev/null
+++ b/arch/x86/kvm/ioapic.h
@@ -0,0 +1,95 @@
+#ifndef __KVM_IO_APIC_H
+#define __KVM_IO_APIC_H
+
+#include linux/kvm_host.h
+
+#include iodev.h
+
+struct kvm;
+struct kvm_vcpu;
+
+#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
+#define IOAPIC_VERSION_ID 0x11 /* IOAPIC version */
+#define IOAPIC_EDGE_TRIG 0
+#define IOAPIC_LEVEL_TRIG 1
+
+#define IOAPIC_DEFAULT_BASE_ADDRESS 0xfec0
+#define IOAPIC_MEM_LENGTH0x100
+
+/* Direct registers. */
+#define IOAPIC_REG_SELECT 0x00
+#define IOAPIC_REG_WINDOW 0x10
+#define IOAPIC_REG_EOI 0x40/* IA64 IOSAPIC only */
+
+/* Indirect registers. */
+#define IOAPIC_REG_APIC_ID 0x00/* x86 IOAPIC only */
+#define IOAPIC_REG_VERSION 0x01
+#define IOAPIC_REG_ARB_ID 0x02/* x86 IOAPIC only */
+
+/*ioapic delivery mode*/
+#defineIOAPIC_FIXED0x0
+#defineIOAPIC_LOWEST_PRIORITY 0x1
+#defineIOAPIC_PMI 0x2
+#defineIOAPIC_NMI 0x4
+#defineIOAPIC_INIT 0x5
+#defineIOAPIC_EXTINT 0x7
+
+struct kvm_ioapic {
+ u64 base_address;
+ u32 ioregsel;
+ u32 id;
+ u32 irr;
+ u32 pad;
+ union ioapic_redir_entry {
+ u64 bits;
+ struct {
+ u8 vector;
+ u8 delivery_mode:3;
+ u8 dest_mode:1;
+ u8 delivery_status:1;
+ u8 polarity:1;
+ u8 remote_irr:1;
+ u8 trig_mode:1;
+ u8 mask:1;
+ u8 reserve:7;
+ u8 reserved[4];
+ u8 dest_id;
+ } fields;
+ } redirtbl[IOAPIC_NUM_PINS];
+ struct kvm_io_device dev;
+ struct kvm *kvm;
+};
+
+#ifdef DEBUG
+#define ASSERT(x)
\
+do {
\
+ if (!(x)) {
\
+ printk(KERN_EMERG assertion failed %s: %d: %s\n,
\
+ __FILE__, __LINE__, #x);
\
+ BUG();
\
+ }
\
+} while (0)
+#else
+#define ASSERT(x) do { } while (0)
+#endif
+
+static inline struct kvm_ioapic *ioapic_irqchip(struct kvm *kvm)
+{
+ return kvm-arch.vioapic;
+}
+
+#ifdef CONFIG_IA64
+static inline int irqchip_in_kernel(struct kvm *kvm)
+{
+ return 1;
+}
+#endif
+
+struct kvm_vcpu *kvm_get_lowest_prio_vcpu(struct kvm *kvm, u8 vector,
+ unsigned long bitmap);
+void kvm_ioapic_update_eoi(struct kvm *kvm, int vector);
+int kvm_ioapic_init(struct kvm *kvm);
+void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level);
+void kvm_ioapic_reset(struct kvm_ioapic *ioapic);
+
+#endif
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 6316638..c376b5b 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -25,7 +25,10 @@
#include linux/mm_types.h
#include linux/hrtimer.h
#include linux/kvm_host.h
+
#include iodev.h
+#include ioapic.h
+#include lapic.h
struct kvm;
struct kvm_vcpu;
@@ -65,131 +68,23 @@ void kvm_pic_set_irq(void *opaque, int irq, int
level);
int kvm_pic_read_irq(struct kvm_pic *s);
void kvm_pic_update_irq(struct kvm_pic *s);
-#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
-#define IOAPIC_VERSION_ID 0x11 /* IOAPIC version */
-#define IOAPIC_EDGE_TRIG 0
-#define IOAPIC_LEVEL_TRIG 1
-
-#define IOAPIC_DEFAULT_BASE_ADDRESS 0xfec0
-#define IOAPIC_MEM_LENGTH0x100
-
-/* Direct registers. */
-#define IOAPIC_REG_SELECT 0x00
-#define IOAPIC_REG_WINDOW 0x10
-#define IOAPIC_REG_EOI 0x40/* IA64 IOSAPIC only */
-
-/* Indirect registers. */
-#define IOAPIC_REG_APIC_ID 0x00/* x86 IOAPIC only */
-#define IOAPIC_REG_VERSION 0x01
-#define IOAPIC_REG_ARB_ID 0x02/* x86 IOAPIC only
[kvm-devel] KVM Test result, kernel 5ca24d9.., userspace 120e0c8..
Hi, This is today's KVM test result against kvm.git 5ca24d96dbc31d7018bc71e355f824f25b70316e and kvm-userspace.git 120e0c89ac05bdbe63aa83389f051e67af037968. No new issue has been found. Save/restore still passes on IA32e host but fails on IA32 host. Issues: 1. PAE host hanged on some platforms while booting guests https://sourceforge.net/tracker/index.php?func=detailaid=1849200group_id=180599atid=893831 2. Crashme causes RHEL5 guest kernel panic The guest will kernel panic immediately after starting the test. https://sourceforge.net/tracker/?func=detailatid=893831aid=1840711group_id=180599 3. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080group_id=180599 4. Cannot install 64bit vista guests. https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905group_id=180599 5. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_id=180599atid=893831 6. xp and win2k3 guest crashes https://sourceforge.net/tracker/?func=detailatid=893831aid=1819768group_id=180599 7. xpsp2 with 2vpus may fail to boot https://sourceforge.net/tracker/index.php?func=detailaid=1805017group_id=180599atid=893831 8. Cannot boot 32bit smp RHEL5.1 guest on 64bit host https://sourceforge.net/tracker/?func=detailatid=893831aid=1812043group_id=180599 Test environment Platform woodcrest CPU 4 Memory size 8G' Details PAE: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled FAIL 7. boot Windows xp with ACPI enabled FAIL 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guest PASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests FAIL 13. live migration 32-bit HVM guests FAIL 14. boot SMP Windows xp with ACPI enabled FAIL 15. boot SMP windows 2003 with ACPI enabled FAIL 16. boot SMP Windows 2000 with ACPI enabled FAIL IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallel PASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 16. boot 32-bit SMP Windows xp with ACPI enabled FAIL 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled PASS 19. boot 32-bit Windows xp without ACPI PASS 20. boot 64-bit vista PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on SMP 32-bit linux guest OS PASS 24. LTP on SMP 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit x-server PASS 27. boot 64-bit SMP windows XP with ACPI enabled FAIL 28. boot 64-bit SMP windows 2003 with ACPI enabled FAIL 29. live migration 64bit linux guests PASS 30. live migration 32bit linux guests PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash
