[PATCH] kvm : qemu: fix compilation error with old kernel
The function hrtimer_start_expires() in the kvm-ia64.c is not supported before the kernel 2.6.28. So we need to hack it. please review it. thanks Signed-off-by: Yang Zhang --- kernel/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index f8b341f..ebf31f8 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -30,7 +30,7 @@ unifdef = mv $1 $1.orig && cat unifdef.h $1.orig > $1 && rm $1.orig hack = $(call _hack,$T/$(strip $1)) hack-files-x86 = kvm_main.c mmu.c vmx.c svm.c x86.c irq.h lapic.c i8254.c kvm_trace.c -hack-files-ia64 = kvm_main.c kvm_fw.c kvm_lib.c +hack-files-ia64 = kvm_main.c kvm_fw.c kvm_lib.c kvm-ia64.c hack-files = $(hack-files-$(ARCH_DIR)) -- 1.6.0.rc1 0001-kvm-qemu-fix-compilation-error-with-old-kernel.patch Description: 0001-kvm-qemu-fix-compilation-error-with-old-kernel.patch
Re: compile problems userspace-tools from git on ubuntu intrepid 8.10 x64
Thank you! Solved my problem! How could i know it without asking the list? greets freisei Zhang, Xiantao schrieb: Did you do "make sync LINUX=/usr/local/src/linux-kvm-git" in kvm-userspace.git before your "./configure" ? Xiantao freisei wrote: Hi @ll, I want to update my kvm-84 to the latest git releaste due to an IOMMU-feature. git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git Problem: kvm support no - (#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS) r...@xp8main3:/usr/local/src/kvm-userspace# ./configure Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /usr/local/src/kvm-userspace/qemu C compilergcc Host C compiler gcc ARCH_CFLAGS -m64 make make install install host CPU x86_64 host big endian no target list x86_64-softmmu gprof enabled no sparse enabledno profiler no static build no -Werror enabled no SDL support yes SDL static link yes curses supportyes mingw32 support no Audio drivers oss Extra audio cards ac97 es1370 sb16 Mixer emulation no VNC TLS support no kqemu support no kvm support no - (#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS) CPU emulation yes brlapi supportno Documentation no NPTL support yes vde support no AIO support yes Install blobs yes KVM support no - (#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS) fdt support no "./configure --with-patched-kernel": same error i´ve changed the code to give me the var "kerneldir" - i think it´s correct: "kerneldir: /lib/modules/2.6.29-rc6-xp8no7/build" then got newest KVM-Kernel with git clone git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git and compiled/installed it the debian/ubuntu way var "kerneldir" - i think it´s correct: "kerneldir: /lib/modules/2.6.29-rc6-xp8no8/build" r...@xp8main3:/usr/local/src/kvm-userspace# ls -la /lib/modules/2.6.29-rc6-xp8no8/build lrwxrwxrwx 1 root root 29 2009-03-02 11:08 /lib/modules/2.6.29-rc6-xp8no8/build -> /usr/local/src/linux-kvm-git/ r...@xp8main3:/usr/local/src/kvm-userspace# ls /usr/local/src/linux-kvm-git/ arch drivers MAINTAINERS samples stamp-indep-conf block firmware Makefilescripts stamp-kernel-headers config.kbuild fsmm security stamp-kernel-image conf.vars include Module.markers sound System.map COPYINGinit modules.order stamp-arch-conf usr CREDITSipc Module.symvers stamp-configurevirt crypto Kbuildnet stamp-configure-arch vmlinux debian kernelREADME stamp-configure-indep vmlinux.o Documentation lib REPORTING-BUGS stamp-debian looks good, i think. but even the same error: I think the configure method doesn´t recognize that i HAVE a kernel with "CAP_DESTROY_MEMORY_REGION_WORKS" found line 1029 in qemu/configure #include which kvm.h is tested here? must be this? r...@xp8main3:/usr/local/src/kvm-userspace# ../linux-kvm-git/include/linux/kvm.h found this lines: /* Bug in KVM_SET_USER_MEMORY_REGION fixed: */ #define KVM_CAP_DESTROY_MEMORY_REGION_WORKS 21 I found it but not the qemu/configure Any suggestions? System is Ubuntu 8.10 x64 greets freisei -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: compile problems userspace-tools from git on ubuntu intrepid 8.10 x64
Did you do "make sync LINUX=/usr/local/src/linux-kvm-git" in kvm-userspace.git before your "./configure" ? Xiantao freisei wrote: > Hi @ll, > > I want to update my kvm-84 to the latest git releaste due to an > IOMMU-feature. > > git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git > > > Problem: kvm support no - (#error Missing KVM capability > KVM_CAP_DESTROY_MEMORY_REGION_WORKS) > > r...@xp8main3:/usr/local/src/kvm-userspace# ./configure > Install prefix/usr/local > BIOS directory/usr/local/share/qemu > binary directory /usr/local/bin > Manual directory /usr/local/share/man > ELF interp prefix /usr/gnemul/qemu-%M > Source path /usr/local/src/kvm-userspace/qemu > C compilergcc > Host C compiler gcc > ARCH_CFLAGS -m64 > make make > install install > host CPU x86_64 > host big endian no > target list x86_64-softmmu > gprof enabled no > sparse enabledno > profiler no > static build no > -Werror enabled no > SDL support yes > SDL static link yes > curses supportyes > mingw32 support no > Audio drivers oss > Extra audio cards ac97 es1370 sb16 > Mixer emulation no > VNC TLS support no > kqemu support no > kvm support no - (#error Missing KVM capability > KVM_CAP_DESTROY_MEMORY_REGION_WORKS) > CPU emulation yes > brlapi supportno > Documentation no > NPTL support yes > vde support no > AIO support yes > Install blobs yes > KVM support no - (#error Missing KVM capability > KVM_CAP_DESTROY_MEMORY_REGION_WORKS) > fdt support no > > "./configure --with-patched-kernel": same error > > i´ve changed the code to give me the var "kerneldir" - i think it´s > correct: "kerneldir: /lib/modules/2.6.29-rc6-xp8no7/build" > > then > got newest KVM-Kernel with git clone > git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git and > compiled/installed it the debian/ubuntu way > > var "kerneldir" - i think it´s correct: "kerneldir: > /lib/modules/2.6.29-rc6-xp8no8/build" > > r...@xp8main3:/usr/local/src/kvm-userspace# ls -la > /lib/modules/2.6.29-rc6-xp8no8/build > lrwxrwxrwx 1 root root 29 2009-03-02 11:08 > /lib/modules/2.6.29-rc6-xp8no8/build -> /usr/local/src/linux-kvm-git/ > > r...@xp8main3:/usr/local/src/kvm-userspace# ls > /usr/local/src/linux-kvm-git/ arch drivers MAINTAINERS > samples > stamp-indep-conf > block firmware Makefilescripts > stamp-kernel-headers > config.kbuild fsmm security > stamp-kernel-image > conf.vars include Module.markers sound > System.map COPYINGinit modules.order stamp-arch-conf > usr > CREDITSipc Module.symvers stamp-configurevirt > crypto Kbuildnet stamp-configure-arch > vmlinux debian kernelREADME > stamp-configure-indep vmlinux.o Documentation lib > REPORTING-BUGS stamp-debian > > looks good, i think. but even the same error: > > I think the configure method doesn´t recognize that i HAVE a kernel > with "CAP_DESTROY_MEMORY_REGION_WORKS" > > found line 1029 in qemu/configure > #include > which kvm.h is tested here? > > must be this? r...@xp8main3:/usr/local/src/kvm-userspace# > ../linux-kvm-git/include/linux/kvm.h > found this lines: > /* Bug in KVM_SET_USER_MEMORY_REGION fixed: */ > #define KVM_CAP_DESTROY_MEMORY_REGION_WORKS 21 > > I found it but not the qemu/configure > > Any suggestions? > > System is Ubuntu 8.10 x64 > > greets freisei -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm: fix irq 0 assignment
On Thursday 05 March 2009 03:41:41 Chris Wright wrote: > * Marcelo Tosatti (mtosa...@redhat.com) wrote: > > Please do not special case irq 0. The fact that only x86/IA64 are > > supported at the moment does not mean other architectures can't > > use it. > > Seems logical to use a flag instead of overloading the irq value. > > > Also, the kernel code to handle dev/irq assignment is quite messy. It > > should be only a mechanism, with userspace controlling the policy. > > I really agree here. I think some work to simplify/clarify would be > time well-spent! So do I... After discussion with Marcelo, I would work with him on this clean up. :) -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-83 write performance raw
Hi Paolo, Sorry, list - getting a bit off-topic but I'll include because it might be of general interest for kvm users ... On Wed, Mar 04, 2009 at 11:28:18PM +0100, Paolo Pedaletti wrote: > ok, I can understand this > but on a big multimedia-file partition an "opportune" read-ahead could > be useful (to set with blockdev) Sure. Adjust and measure for your average and worst-case workload. I expected a moderate read-ahead to help on the storage serving my kvm hosts, but in practice it caused painful latency spikes. > I use LVM extensively so can you explain how can you achieve alignments > between lvm and filesistem? and how to check it? Your links contain good material on this. My comments are: When you can, don't use a partition table but make the whole disk a PV. Otherwise, watch that your partitions are properly aligned. Use '--metadatasize 250k' arguments with pvcreate (the size is always rounded up the next 64KB boundary so 250k ends up 256KB, '--metadatasize 256k' would result in 320KB). 'pvs -o+pe_start' and 'dmsetup table' will show your PV and LV offsets. If you use image files, you probably don't want them to have holes in them, or they will likey fragment as the holes are filled. I expect qcow2 images internally fragment? Read-ahead on a fragmented image file will really hurt. Ext2 doesn't seem very sensitive to alignment. I haven't played with aligning ext3's journal. (Speculation: a deliberately-wrong stride could be interesting if inode lookups are a seek away from their data block and your RAID is clever about splitting seeks between mirror drives.) RAID controllers can have their own sector offsets and read-aheads. Using disk type='block' avoids the host filesystem overhead altogether. Regards, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm : qemu : fix compilation error in kvm-userspace for ia64
Marcelo Tosatti wrote: > On Thu, Mar 05, 2009 at 09:36:13AM +0800, Zhang, Yang wrote: >> seems right, But i cannot find the proper place to define it. >> And i think we can do this at the time of we need to use it. > > The thinking is avoid code from piling in kvm-userspace when it > belongs in upstream QEMU. #ifdef's like that are ugly, but OK. Will > apply. Thank you. > Can you please submit this one to be included in QEMU upstream? > > commit f759e44e04f03798d83de53d2c295965c68126a2 > Author: Yang > Date: Thu Jan 15 13:03:53 2009 +0800 > > kvm: qemu: Save ia64 nvram > Ok.-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm : qemu : fix compilation error in kvm-userspace for ia64
On Thu, Mar 05, 2009 at 09:36:13AM +0800, Zhang, Yang wrote:
> Marcelo Tosatti wrote:
> > On Tue, Mar 03, 2009 at 11:38:17AM +0800, Zhang, Yang wrote:
> >> diff --git a/qemu/hw/i8259.c b/qemu/hw/i8259.c
> >> index 9cb3941..025f993 100644
> >> --- a/qemu/hw/i8259.c
> >> +++ b/qemu/hw/i8259.c
> >> @@ -189,8 +189,10 @@ static void i8259_set_irq(void *opaque, int
> >> irq, int level) if (kvm_enabled()) { int pic_ret;
> >> if (kvm_set_irq(irq, level, &pic_ret)) {
> >> +#ifndef TARGET_IA64
> >> if (pic_ret != 0)
> >> apic_set_irq_delivered();
> >> +#endif
> >
> > Why don't you define apic_set_irq_delivered for IA64?
>
> seems right, But i cannot find the proper place to define it.
> And i think we can do this at the time of we need to use it.
The thinking is avoid code from piling in kvm-userspace when it belongs
in upstream QEMU. #ifdef's like that are ugly, but OK. Will apply.
Can you please submit this one to be included in QEMU upstream?
commit f759e44e04f03798d83de53d2c295965c68126a2
Author: Yang
Date: Thu Jan 15 13:03:53 2009 +0800
kvm: qemu: Save ia64 nvram
Thanks
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm : qemu : fix compilation error in kvm-userspace for ia64
Marcelo Tosatti wrote:
> On Tue, Mar 03, 2009 at 11:38:17AM +0800, Zhang, Yang wrote:
>> diff --git a/qemu/hw/i8259.c b/qemu/hw/i8259.c
>> index 9cb3941..025f993 100644
>> --- a/qemu/hw/i8259.c
>> +++ b/qemu/hw/i8259.c
>> @@ -189,8 +189,10 @@ static void i8259_set_irq(void *opaque, int
>> irq, int level) if (kvm_enabled()) { int pic_ret;
>> if (kvm_set_irq(irq, level, &pic_ret)) {
>> +#ifndef TARGET_IA64
>> if (pic_ret != 0)
>> apic_set_irq_delivered();
>> +#endif
>
> Why don't you define apic_set_irq_delivered for IA64?
seems right, But i cannot find the proper place to define it.
And i think we can do this at the time of we need to use it.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
From: "sudhir kumar" >On Wed, Mar 4, 2009 at 11:45 PM, Ryan Harper wrote: >>> * Uri Lublin [2009-03-04 02:59]: >>> >- guest install wizard using md5sum region matching ... ouch. This is >>> >quite fickle. I've seen different kvms generate different md5sum for >>> >the same region a couple of times. I know distributing screenshots of >>> >certain OSes is a grey area, but it would be nice to plumb through >>> >screenshot comparison and make that configurable. FWIW, I'll probably >>> >look at pulling the screenshot comparison bits from kvmtest and getting >>> >that integrated in kvm_runtest_2. >>> Creating a step file is not as easy as it seems, exactly for that reason. >I agree here 100% as per my experience. >>> One has to pick a part of the screenshot that only available when input is >>> expected and that would be consistent. We were thinking of replacing the >>> md5sum with a tiny compressed image of the part of the image that was >>> picked. >> >> It isn't just that step file creation isn't easy is that even with a >> good stepfile with smart region boxes, md5sum can *still* fail because >> KVM renders one pixel in the region differently than the system where the >> original was created; this creates false positives failures. >I also have faced this issue. Even on the same system the step file >may fail. I saw few(though not frequent) situations where the same >md5sum passed in one time and failed in the other attempt. I think we need something more forgiving than md5sum, which would still be pretty small. Image compression/reduction is what we are thinking of (but have yet to prove it's working and select the best algorithm for our needs). >>> We had two other implementation for guest-wizard, one which only compares >>> two/three consecutive screendumps (problems with e.g. clock ticking), and >> >> Right, I like the idea of the region selection in stepmaker, it lets us >> avoid areas which have VM specific info, like the device path or clock. >> I'd like to keep the current stepmaker and region code, what I'd like to >> see instead of just md5sum compare of the cropped region, to be able to >> plug in different comparisons. If a user does have screens from >> stepmaker available, guest_wizard could attempt to do screen compare >> like we do in kvmtests with match percentages. If no screens are >> available, fallback on md5 or some other comparison algorithm. >That sounds better. Yet none of my step files worked in one go. I >remember running my test and stepmaker parallelly and continue taking >screenshots untill one passes and putting that md5sum in the step >file. That's an interesting way. I have'nt tried that one before. >So at the end I was fully meshed up with respect to the cropped >images and I had no idea which cropped image corresponded to which >md5sum. Step file writes the step number (which is the image number) as a comment for the step. I'm sure (and hope) that after you'd create a few step files, you'd pick the right subimage and the whole process would be much easier. >Though the RHEL5.3 step files that I generated in the text mode >installation were quite strong. That's nice to know. >>> one similar to kvmtest. The kvmtest way is to let the user create his/her >>> own screendumps to be used later. I did not want to add so many screendumps >>> images to the repository. Step-Maker keeps the images it uses, so we can >>> compare them upon failure. Step-Editor lets the user to change a single >>> barrier_2 step (or more) by looking at the original image and picking a >>> different area. >> >> Agreed, I don't want to commit screens to the repo either, I just want >> to be able to use screens if a user has them available. >> >I have two questions with respect to stepfiles. >1. The timeouts: Timeouts may fall short if a step file generated on a >high end machine is to be used on a very low config machine or >installing N virtual machines (say N ~ 50,100 etc) in parallel. For those reasons, among others, we set the timeout to 5 times what the step actually took. Since creating the step file is human driven (compared to running the installation) effectively the multiplication is even higher. That also creates a problem when guest installation fails. We thought of a very quick and simple benchmark. We would run it in step-maker and write the score in the step file. And we would run it before guest installation. We'd adjust the timeout accordingly. >2. If there are changes in KVM display in future the md5sum will fail. >So are we prepared for that? It happened to us when suspend capability was added. I do not think you can be prepared for that. The before/after screens are different. We have step-editor for that. Using step-editor we can change the step that failed due to the change (adjust it to the "after" screendump or choosing a different region), and hopefully guest installation would be successful again. Uri. -- To unsubscribe from this list: send the line "unsubs
Re: kvm-autotest -- introducing kvm_runtest_2
From: "Ryan Harper" > Uri Lublin [2009-03-04 02:59]: >> >> > - it seems like the definition and rules ought to be separate from the >> > last section which defines which tests to run (the fc8_quick area), so >> > adding something as simple as include support to kvm_config.py would >> > be sufficient to support a common definition file but different >> > testing rules. >> An include support is one way to do it. We thought of a different way, >> which is >> to add rules from the control file. So the control file would pick the >> test-list >> it wants to run. Your suggestion is simpler but you need both a config file >> and >> a control file to change the test-list. We need to change only the control >> file. > >OK, well, I viewed almost all of the test config file as static. The >rules about guests, features, config variants, can change over time, but >not that often which is what I was wanting an include of that mostly >static data and then something else that picked which guests and tests >to run. It does make sense for the control file to pick the set of >tests, so I think we're in agreement, though I do think adding include >support is still a good idea, but much lower on the priority list. OK. Shouldn't be too hard. >> >> >> > >> >- kvm_runtest_2 as mentioned doesn't mess with your host networking and >> >relies on -net user and redir, would be good to plumb through -net tap >> >support that can be configured instead of always using -net user >> We want to add -net tap support, as that is what users usually use. >> kvm_runtest does exactly that (a part of kvm_host.cfg). The drawbacks of >> tap are >> (among others): >> - One must run tests as root, or play with sudo/chmod (True for /dev/kvm, >> but >> simpler) >> - You have to a have a dhcpd around. kvm_runtest by default runs a local >> dhcpd >> to serve kvm guests (part of setup/cleanup tests). >> - A bit more difficult to configure. >> >I don't want to have the test *setup* tap and all of the infrastructure >like dhcp, or dnsmasq... I just want to be able to configure whether a >guest is launched with -net tap or -net user. kvm_runtest_2 punts on >building and install kvm as well as the networking, which is a great >idea, I just want to be flexible enough to run kvm_runtest_2 with -net >tap as well as -net user. I agree we want to enable -net tap. I've just mentioned the drawbacks of it. We want to add kvm_install to kvm_runtest_2. It's important to build kvm on the client. It would be nice to also use it to build kvm on guests. >> > >> >I noticed the references to the setup isos for windows that presumbly >> >install cygwin telnetd/sshd, are those available? if the isos >> >themselves aren't, if the build instructions are, that would be very >> >useful. >> You are right. We do have an installation iso images for telnetd/sshd. >> I did not want to commit iso images. Also, I am not sure about licensing, >> and I prefer that we would generate them on the user machine. We'll add the >> build instructions to the wiki. > >Agreed. Sounds like a plan. >> >- guest install wizard using md5sum region matching ... ouch. This is >> >quite fickle. I've seen different kvms generate different md5sum for >> >the same region a couple of times. I know distributing screenshots of >> >certain OSes is a grey area, but it would be nice to plumb through >> >screenshot comparison and make that configurable. FWIW, I'll probably >> >look at pulling the screenshot comparison bits from kvmtest and getting >> >that integrated in kvm_runtest_2. >> Creating a step file is not as easy as it seems, exactly for that reason. >> One has to pick a part of the screenshot that only available when input is >> expected and that would be consistent. We were thinking of replacing the >> md5sum with a tiny compressed image of the part of the image that was >> picked. >It isn't just that step file creation isn't easy is that even with a >good stepfile with smart region boxes, md5sum can *still* fail because >KVM renders one pixel in the region differently than the system where the >original was created; this creates false positives failures. We need something more "forgiving" than md5sum, that would still be a compact representation of the region box. We may be able to use an image compression algorithm (need to investigate on that). That's what I meant by "tiny compressed image". >> We had two other implementation for guest-wizard, one which only compares >> two/three consecutive screendumps (problems with e.g. clock ticking), and >Right, I like the idea of the region selection in stepmaker, it lets us >avoid areas which have VM specific info, like the device path or clock. >I'd like to keep the current stepmaker and region code, what I'd like to >see instead of just md5sum compare of the cropped region, to be able to >plug in different comparisons. If a user does have screens from >stepmaker available, guest_wizard could attempt to do scre
Re: kvm-84 kernel panic
On Wed, Mar 04, 2009 at 02:10:30PM +0100, Johannes Baumann wrote: > Hi, > > i had serveral kernel panics in the last days on a DELL R300. > First i had ubuntu 8.10 running with latest kvm compiled. > the panic looked like this: http://memic.paniert.org/screen.png > > The impi log looks like this > > 2d | 02/19/2009 | 02:54:31 | Processor #0x0d | Transition to > Non-recoverable > 2e | 02/19/2009 | 02:54:32 | Processor #0x60 | IERR | Asserted > 32 | 02/19/2009 | 14:55:52 | Processor #0x0d | Transition to > Non-recoverable > 33 | 02/24/2009 | 23:00:14 | Processor #0x0d | Transition to > Non-recoverable > 37 | 02/25/2009 | 22:58:02 | Processor #0x0d | Transition to > Non-recoverable > 38 | 03/03/2009 | 13:59:03 | Processor #0x0d | Transition to > Non-recoverable > 39 | 03/03/2009 | 17:41:34 | Processor #0x0d | Transition to > Non-recoverable > 3a | 03/04/2009 | 07:41:02 | Processor #0x0d | Transition to > Non-recoverable > 3b | 03/04/2009 | 11:03:23 | Processor #0x0d | Transition to > Non-recoverable > 3c | 03/04/2009 | 11:03:26 | Processor #0x60 | IERR | Asserted > 3d | 03/04/2009 | 11:08:16 | Processor #0x60 | IERR | Deasserted > > Right now i have fedora 10 as host system running, with the newest kvm > version. My CPU is Intel(R) Xeon(R) CPU X3363 @ 2.83GHz Quadcore. > I have 2 Windows 2003 Enterprise Domains running at almost no load. > Im not sure when to panic happens but it think its reproducable if the > guest systems are under load. > > What can i do to get more debug information? http://en.wikipedia.org/wiki/Machine_Check_Exception See the "Decoding MCEs" section. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-83 write performance raw
Ciao Mark, RAID1 has *much* better write performance. With striping RAIDs, alignment is important. RAID controllers sometimes introduce hidden alignment offsets. Excessive read-ahead is a waste of time with a lot of small random I/O, which is what I see mostly with guests on flat disk images. ok, I can understand this but on a big multimedia-file partition an "opportune" read-ahead could be useful (to set with blockdev) With LVM, it pays to make sure the LVs are aligned to the disk. I prefer boundaries with multiples of at least 64-sectors, which makes the LVM overhead virtually disappear. I align the guest filesystems too, when I can. I use LVM extensively so can you explain how can you achieve alignments between lvm and filesistem? and how to check it? I have found this interesting: http://www.mail-archive.com/linux-r...@vger.kernel.org/msg09685.html http://kerneltrap.org/mailarchive/linux-raid/2008/12/1/4272764 http://blog.endpoint.com/2008/09/filesystem-io-what-we-presented.html http://lonesysadmin.net/2009/01/02/how-to-grow-linux-virtual-disks-in-vmware/ (useful even for kvm users :-) http://orezpraw.com/blog/your-filesystem-starts-where http://www.issociate.de/board/post/464221/stride_/_stripe_alignment_on_LVM_?.html http://www.ocztechnologyforum.com/forum/showpost.php?p=335049&postcount=134 http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ I've post this links because: 1) I didn't know this alignment-problem 2) lvm is suggested as preferred/best solution instead qcow2 file-image 3) filesystem performance may not related to kvm driver 4) I still have to read those post and understand them :-) thank you... -- Paolo Pedaletti -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
sudhir kumar wrote: On Wed, Mar 4, 2009 at 11:45 PM, Ryan Harper wrote: * Uri Lublin [2009-03-04 02:59]: - it seems like the definition and rules ought to be separate from the last section which defines which tests to run (the fc8_quick area), so adding something as simple as include support to kvm_config.py would be sufficient to support a common definition file but different testing rules. An include support is one way to do it. We thought of a different way, which is to add rules from the control file. So the control file would pick the test-list it wants to run. Your suggestion is simpler but you need both a config file and a control file to change the test-list. We need to change only the control file. OK, well, I viewed almost all of the test config file as static. The rules about guests, features, config variants, can change over time, but not that often which is what I was wanting an include of that mostly static data and then something else that picked which guests and tests to run. It does make sense for the control file to pick the set of tests, so I think we're in agreement, though I do think adding include support is still a good idea, but much lower on the priority list. - kvm_runtest_2 as mentioned doesn't mess with your host networking and relies on -net user and redir, would be good to plumb through -net tap support that can be configured instead of always using -net user We want to add -net tap support, as that is what users usually use. kvm_runtest does exactly that (a part of kvm_host.cfg). The drawbacks of tap are (among others): - One must run tests as root, or play with sudo/chmod (True for /dev/kvm, but simpler) - You have to a have a dhcpd around. kvm_runtest by default runs a local dhcpd to serve kvm guests (part of setup/cleanup tests). - A bit more difficult to configure. I don't want to have the test *setup* tap and all of the infrastructure like dhcp, or dnsmasq... I just want to be able to configure whether a guest is launched with -net tap or -net user. kvm_runtest_2 punts on building and install kvm as well as the networking, which is a great idea, I just want to be flexible enough to run kvm_runtest_2 with -net tap as well as -net user. I noticed the references to the setup isos for windows that presumbly install cygwin telnetd/sshd, are those available? if the isos themselves aren't, if the build instructions are, that would be very useful. You are right. We do have an installation iso images for telnetd/sshd. I did not want to commit iso images. Also, I am not sure about licensing, and I prefer that we would generate them on the user machine. We'll add the build instructions to the wiki. Agreed. Sounds like a plan. - guest install wizard using md5sum region matching ... ouch. This is quite fickle. I've seen different kvms generate different md5sum for the same region a couple of times. I know distributing screenshots of certain OSes is a grey area, but it would be nice to plumb through screenshot comparison and make that configurable. FWIW, I'll probably look at pulling the screenshot comparison bits from kvmtest and getting that integrated in kvm_runtest_2. Creating a step file is not as easy as it seems, exactly for that reason. I agree here 100% as per my experience. One has to pick a part of the screenshot that only available when input is expected and that would be consistent. We were thinking of replacing the md5sum with a tiny compressed image of the part of the image that was picked. It isn't just that step file creation isn't easy is that even with a good stepfile with smart region boxes, md5sum can *still* fail because KVM renders one pixel in the region differently than the system where the original was created; this creates false positives failures. I also have faced this issue. Even on the same system the step file may fail. I saw few(though not frequent) situations where the same md5sum passed in one time and failed in the other attempt. Maybe we can do some type of graphic processing to the original bitmap to reduce its quality drastically, then do the md5sum. It won't be 100% process but can deal with most problems. Anyway I don't think we run into these issues here. As a rule of the thumb I like to first use kickstart files instead of step maker files when possible. It will take the timing issue out of the equation. It is very important for running the same test over plain qemu and kvm. Windows also has its version of it (answer files) so even the 'gui' OS can be used with it. We had two other implementation for guest-wizard, one which only compares two/three consecutive screendumps (problems with e.g. clock ticking), and Right, I like the idea of the region selection in stepmaker, it lets us avoid areas which have VM specific info, like the device path or clock. I'd like to keep the cu
Re: kvm-84 kernel panic
update: the kernel panics just seem to happen with smp guests, right now i have only non smp guest and everything is fine, even under load. is this a known problem? Johannes Baumann schrieb: > Hi, > > i had serveral kernel panics in the last days on a DELL R300. > First i had ubuntu 8.10 running with latest kvm compiled. > the panic looked like this: http://memic.paniert.org/screen.png > > The impi log looks like this > > 2d | 02/19/2009 | 02:54:31 | Processor #0x0d | Transition to > Non-recoverable > 2e | 02/19/2009 | 02:54:32 | Processor #0x60 | IERR | Asserted > 32 | 02/19/2009 | 14:55:52 | Processor #0x0d | Transition to > Non-recoverable > 33 | 02/24/2009 | 23:00:14 | Processor #0x0d | Transition to > Non-recoverable > 37 | 02/25/2009 | 22:58:02 | Processor #0x0d | Transition to > Non-recoverable > 38 | 03/03/2009 | 13:59:03 | Processor #0x0d | Transition to > Non-recoverable > 39 | 03/03/2009 | 17:41:34 | Processor #0x0d | Transition to > Non-recoverable > 3a | 03/04/2009 | 07:41:02 | Processor #0x0d | Transition to > Non-recoverable > 3b | 03/04/2009 | 11:03:23 | Processor #0x0d | Transition to > Non-recoverable > 3c | 03/04/2009 | 11:03:26 | Processor #0x60 | IERR | Asserted > 3d | 03/04/2009 | 11:08:16 | Processor #0x60 | IERR | Deasserted > > Right now i have fedora 10 as host system running, with the newest kvm > version. My CPU is Intel(R) Xeon(R) CPU X3363 @ 2.83GHz Quadcore. > I have 2 Windows 2003 Enterprise Domains running at almost no load. > Im not sure when to panic happens but it think its reproducable if the > guest systems are under load. > > What can i do to get more debug information? > > Thx so far.. Johannes > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm: fix irq 0 assignment
* Marcelo Tosatti (mtosa...@redhat.com) wrote: > Please do not special case irq 0. The fact that only x86/IA64 are > supported at the moment does not mean other architectures can't > use it. Seems logical to use a flag instead of overloading the irq value. > Also, the kernel code to handle dev/irq assignment is quite messy. It > should be only a mechanism, with userspace controlling the policy. I really agree here. I think some work to simplify/clarify would be time well-spent! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm: fix irq 0 assignment
On Wed, Mar 04, 2009 at 03:54:27PM +0800, Sheng Yang wrote:
> Shouldn't update assigned irq if host irq is 0, which means uninitialized
> or don't support INTx.
>
> Signed-off-by: Sheng Yang
> ---
> qemu/hw/device-assignment.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
> index 32fba2a..7f9c789 100644
> --- a/qemu/hw/device-assignment.c
> +++ b/qemu/hw/device-assignment.c
> @@ -574,6 +574,10 @@ static int assign_irq(AssignedDevInfo *adev)
> AssignedDevice *dev = adev->assigned_dev;
> int irq, r = 0;
>
> +/* irq 0 means uninitialized */
> +if (dev->real_device.irq == 0)
> +return 0;
> +
> irq = pci_map_irq(&dev->dev, dev->intpin);
> irq = piix_get_irq(irq);
Sheng,
Please do not special case irq 0. The fact that only x86/IA64 are
supported at the moment does not mean other architectures can't
use it.
Also, the kernel code to handle dev/irq assignment is quite messy. It
should be only a mechanism, with userspace controlling the policy.
For example:
if (match->irq_requested_type & KVM_ASSIGNED_DEV_MSIX)
current_flags |= KVM_DEV_IRQ_ASSIGN_ENABLE_MSIX;
else if ((match->irq_requested_type & KVM_ASSIGNED_DEV_HOST_MSI) &&
(match->irq_requested_type & KVM_ASSIGNED_DEV_GUEST_MSI))
current_flags |= KVM_DEV_IRQ_ASSIGN_ENABLE_MSI;
And then in userspace you have
+if (*ctrl_word & PCI_MSIX_ENABLE) {
+assigned_irq_data.flags = KVM_DEV_IRQ_ASSIGN_ENABLE_MSIX;
+if (assigned_dev_update_msix_mmio(pci_dev) < 0) {
+perror("assigned_dev_update_msix_mmio");
+}
+}
We really need to fix this before merging anything else in this area.
So ideally the kernel only provides ioctl commands that do one thing
at a time:
- assign host device
- unassign guest device
- assign host irq (INTx or MSI)
- assign dev irq (INTx or MSI)
- unassign host irq
- unassign dev irq
So you don't have to make policy decisions like
} else {
/*
* Guest require to disable device MSI, we disable MSI
* and
* re-enable INTx by default again. Notice it's only for
* non-msi2intx.
*/
assigned_device_update_intx(kvm, adev, airq);
return 0;
}
Because you do in userspace. However, I do not think it is necessary to
create new ioctl commands and deprecate the old ones (it seems possible
to do this using the flags passed in "struct kvm_assigned_irq")
However, the current userspace code probably relies on implicit
behaviour by the kernel part. IMHO it is fair to break older
userspace. Better change it sooner than later.
For example, don't do this
if ((changed_flags & KVM_DEV_IRQ_ASSIGN_MSI_ACTION) ||
(msi2intx && match->dev->msi_enabled)) {
But just enable MSI in either host or guest (one at a time). Return an
error if you can't. And don't make such assumptions:
} else if (assigned_irq->host_irq == 0 && match->dev->irq == 0)
/* Host device IRQ 0 means don't support INTx */
To use the current ioctl commands, maybe enforce the "one thing at a
time" nature and fail otherwise.
Can you please investigate about this possibility? Because talk is
cheap and I'm not sure whether you can always separate host/guest IRQ
assignment, but probably as long as done carefully.
Am I missing any reason why policy can't live outside the kernel?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
On Wed, Mar 4, 2009 at 11:45 PM, Ryan Harper wrote: > * Uri Lublin [2009-03-04 02:59]: >> >> > - it seems like the definition and rules ought to be separate from the >> > last section which defines which tests to run (the fc8_quick area), so >> > adding something as simple as include support to kvm_config.py would >> > be sufficient to support a common definition file but different >> > testing rules. >> An include support is one way to do it. We thought of a different way, >> which is >> to add rules from the control file. So the control file would pick the >> test-list >> it wants to run. Your suggestion is simpler but you need both a config file >> and >> a control file to change the test-list. We need to change only the control >> file. > > OK, well, I viewed almost all of the test config file as static. The > rules about guests, features, config variants, can change over time, but > not that often which is what I was wanting an include of that mostly > static data and then something else that picked which guests and tests > to run. It does make sense for the control file to pick the set of > tests, so I think we're in agreement, though I do think adding include > support is still a good idea, but much lower on the priority list. > >> >> > >> >- kvm_runtest_2 as mentioned doesn't mess with your host networking and >> >relies on -net user and redir, would be good to plumb through -net tap >> >support that can be configured instead of always using -net user >> We want to add -net tap support, as that is what users usually use. >> kvm_runtest does exactly that (a part of kvm_host.cfg). The drawbacks of >> tap are >> (among others): >> - One must run tests as root, or play with sudo/chmod (True for /dev/kvm, >> but >> simpler) >> - You have to a have a dhcpd around. kvm_runtest by default runs a local >> dhcpd >> to serve kvm guests (part of setup/cleanup tests). >> - A bit more difficult to configure. >> > > I don't want to have the test *setup* tap and all of the infrastructure > like dhcp, or dnsmasq... I just want to be able to configure whether a > guest is launched with -net tap or -net user. kvm_runtest_2 punts on > building and install kvm as well as the networking, which is a great > idea, I just want to be flexible enough to run kvm_runtest_2 with -net > tap as well as -net user. > > >> > >> >I noticed the references to the setup isos for windows that presumbly >> >install cygwin telnetd/sshd, are those available? if the isos >> >themselves aren't, if the build instructions are, that would be very >> >useful. >> You are right. We do have an installation iso images for telnetd/sshd. >> I did not want to commit iso images. Also, I am not sure about licensing, >> and I prefer that we would generate them on the user machine. We'll add the >> build instructions to the wiki. > > Agreed. Sounds like a plan. > >> >- guest install wizard using md5sum region matching ... ouch. This is >> >quite fickle. I've seen different kvms generate different md5sum for >> >the same region a couple of times. I know distributing screenshots of >> >certain OSes is a grey area, but it would be nice to plumb through >> >screenshot comparison and make that configurable. FWIW, I'll probably >> >look at pulling the screenshot comparison bits from kvmtest and getting >> >that integrated in kvm_runtest_2. >> Creating a step file is not as easy as it seems, exactly for that reason. I agree here 100% as per my experience. >> One has to pick a part of the screenshot that only available when input is >> expected and that would be consistent. We were thinking of replacing the >> md5sum with a tiny compressed image of the part of the image that was >> picked. > > It isn't just that step file creation isn't easy is that even with a > good stepfile with smart region boxes, md5sum can *still* fail because > KVM renders one pixel in the region differently than the system where the > original was created; this creates false positives failures. I also have faced this issue. Even on the same system the step file may fail. I saw few(though not frequent) situations where the same md5sum passed in one time and failed in the other attempt. > > >> We had two other implementation for guest-wizard, one which only compares >> two/three consecutive screendumps (problems with e.g. clock ticking), and > > Right, I like the idea of the region selection in stepmaker, it lets us > avoid areas which have VM specific info, like the device path or clock. > I'd like to keep the current stepmaker and region code, what I'd like to > see instead of just md5sum compare of the cropped region, to be able to > plug in different comparisons. If a user does have screens from > stepmaker available, guest_wizard could attempt to do screen compare > like we do in kvmtests with match percentages. If no screens are > available, fallback on md5 or some other comparison algorithm. That sounds better. Yet none of my step files worked in one go. I rememb
Re: [PATCH 1/1] KVM: Merge kvm_ioapic_get_delivery_bitmask into kvm_get_intr_delivery_bitmask
On Wed, Mar 04, 2009 at 01:33:02PM +0800, Sheng Yang wrote:
> Gleb fixed bitmap ops usage in kvm_ioapic_get_delivery_bitmask.
>
> Sheng merged two functions, as well as fixed several issues in
> kvm_get_intr_delivery_bitmask
> 1. deliver_bitmask is a bitmap rather than a unsigned long intereger.
> 2. Lowest priority target bitmap wrong calculated by mistake.
> 3. Prevent potential NULL reference.
> 4. Declaration in include/kvm_host.h caused powerpc compilation warning.
> 5. Add warning for guest broadcast interrupt with lowest priority delivery
> mode.
> 6. Removed duplicate bitmap clean up in caller of
> kvm_get_intr_delivery_bitmask.
>
> Signed-off-by: Gleb Natapov
> Signed-off-by: Sheng Yang
> + bitmap_zero(deliver_bitmask, KVM_MAX_VCPUS);
> +
> + if (entry->fields.dest_mode == 0) { /* Physical mode. */
> + if (entry->fields.dest_id == 0xFF) {/* Broadcast. */
> + /* Lowest priority shouldn't combine with broadcast */
> + WARN_ON(entry->fields.delivery_mode ==
> + IOAPIC_LOWEST_PRIORITY);
Applied with two changes:
- printk(KERN_INFO) with printk_ratelimit instead of WARN.
- bitmap_zero in the irq == 0 case.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
* Uri Lublin [2009-03-04 02:59]: > > > - it seems like the definition and rules ought to be separate from the > > last section which defines which tests to run (the fc8_quick area), so > > adding something as simple as include support to kvm_config.py would > > be sufficient to support a common definition file but different > > testing rules. > An include support is one way to do it. We thought of a different way, > which is > to add rules from the control file. So the control file would pick the > test-list > it wants to run. Your suggestion is simpler but you need both a config file > and > a control file to change the test-list. We need to change only the control > file. OK, well, I viewed almost all of the test config file as static. The rules about guests, features, config variants, can change over time, but not that often which is what I was wanting an include of that mostly static data and then something else that picked which guests and tests to run. It does make sense for the control file to pick the set of tests, so I think we're in agreement, though I do think adding include support is still a good idea, but much lower on the priority list. > > > > >- kvm_runtest_2 as mentioned doesn't mess with your host networking and > >relies on -net user and redir, would be good to plumb through -net tap > >support that can be configured instead of always using -net user > We want to add -net tap support, as that is what users usually use. > kvm_runtest does exactly that (a part of kvm_host.cfg). The drawbacks of > tap are > (among others): > - One must run tests as root, or play with sudo/chmod (True for /dev/kvm, > but > simpler) > - You have to a have a dhcpd around. kvm_runtest by default runs a local > dhcpd > to serve kvm guests (part of setup/cleanup tests). > - A bit more difficult to configure. > I don't want to have the test *setup* tap and all of the infrastructure like dhcp, or dnsmasq... I just want to be able to configure whether a guest is launched with -net tap or -net user. kvm_runtest_2 punts on building and install kvm as well as the networking, which is a great idea, I just want to be flexible enough to run kvm_runtest_2 with -net tap as well as -net user. > > > >I noticed the references to the setup isos for windows that presumbly > >install cygwin telnetd/sshd, are those available? if the isos > >themselves aren't, if the build instructions are, that would be very > >useful. > You are right. We do have an installation iso images for telnetd/sshd. > I did not want to commit iso images. Also, I am not sure about licensing, > and I prefer that we would generate them on the user machine. We'll add the > build instructions to the wiki. Agreed. Sounds like a plan. > >- guest install wizard using md5sum region matching ... ouch. This is > >quite fickle. I've seen different kvms generate different md5sum for > >the same region a couple of times. I know distributing screenshots of > >certain OSes is a grey area, but it would be nice to plumb through > >screenshot comparison and make that configurable. FWIW, I'll probably > >look at pulling the screenshot comparison bits from kvmtest and getting > >that integrated in kvm_runtest_2. > Creating a step file is not as easy as it seems, exactly for that reason. > One has to pick a part of the screenshot that only available when input is > expected and that would be consistent. We were thinking of replacing the > md5sum with a tiny compressed image of the part of the image that was > picked. It isn't just that step file creation isn't easy is that even with a good stepfile with smart region boxes, md5sum can *still* fail because KVM renders one pixel in the region differently than the system where the original was created; this creates false positives failures. > We had two other implementation for guest-wizard, one which only compares > two/three consecutive screendumps (problems with e.g. clock ticking), and Right, I like the idea of the region selection in stepmaker, it lets us avoid areas which have VM specific info, like the device path or clock. I'd like to keep the current stepmaker and region code, what I'd like to see instead of just md5sum compare of the cropped region, to be able to plug in different comparisons. If a user does have screens from stepmaker available, guest_wizard could attempt to do screen compare like we do in kvmtests with match percentages. If no screens are available, fallback on md5 or some other comparison algorithm. > one similar to kvmtest. The kvmtest way is to let the user create his/her > own screendumps to be used later. I did not want to add so many screendumps > images to the repository. Step-Maker keeps the images it uses, so we can > compare them upon failure. Step-Editor lets the user to change a single > barrier_2 step (or more) by looking at the original image and picking a > different area. Agreed, I don't want to commit screens to the repo either,
Re: [PATCH 3/3] Consolidate ioapic/ipi interrupt delivery logic.
On Wed, Mar 04, 2009 at 03:30:22PM +0200, Gleb Natapov wrote:
> Use kvm_apic_match_dest() in kvm_get_intr_delivery_bitmask() instead
> of duplicating the same code. Use kvm_get_intr_delivery_bitmask() in
> apic_send_ipi() to figure out ipi destination instead of reimplementing
> the logic.
>
> Signed-off-by: Gleb Natapov
> ---
> -struct kvm_vcpu *kvm_get_lowest_prio_vcpu(struct kvm *kvm, u8 vector,
> - unsigned long *bitmap)
> -{
> - struct kvm_lapic *apic;
> -
> - apic = kvm_apic_round_robin(kvm, vector, bitmap);
> - if (apic)
> - return apic->vcpu;
> - return NULL;
> + return vcpu1->arch.apic_arb_prio - vcpu2->arch.apic_arb_prio;
> }
Can you split the round robin logic change to a separate patch, and
have only code unification in this?
Also mind the tabs.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Make kvm_apic_set_irq() deliver all kinds of interrupts.
Hi Gleb,
On Wed, Mar 04, 2009 at 03:30:11PM +0200, Gleb Natapov wrote:
> Get rid of ioapic_inj_irq() and ioapic_inj_nmi() functions.
>
> Signed-off-by: Gleb Natapov
> ---
>
> index afc59b2..d58268f 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -196,20 +196,30 @@ int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
> }
> EXPORT_SYMBOL_GPL(kvm_lapic_find_highest_irr);
>
> -int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig)
> +static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,
> + int vector, int level, int trig_mode);
> +
> +int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 dmode, u8 trig)
> {
> struct kvm_lapic *apic = vcpu->arch.apic;
> + int lapic_dmode;
>
> - if (!apic_test_and_set_irr(vec, apic)) {
> - /* a new pending irq is set in IRR */
> - if (trig)
> - apic_set_vector(vec, apic->regs + APIC_TMR);
> - else
> - apic_clear_vector(vec, apic->regs + APIC_TMR);
> - kvm_vcpu_kick(apic->vcpu);
> - return 1;
> + switch(dmode) {
> + case IOAPIC_LOWEST_PRIORITY:
> + lapic_dmode = APIC_DM_LOWEST;
> + break;
> + case IOAPIC_FIXED:
> + lapic_dmode = APIC_DM_FIXED;
> + break;
> + case IOAPIC_NMI:
> + lapic_dmode = APIC_DM_NMI;
> + break;
> + default:
> + printk(KERN_DEBUG"Ignoring delivery mode %d\n", dmode);
> + return 0;
> + break;
> }
> - return 0;
> + return __apic_accept_irq(apic, lapic_dmode, vec, 1, trig);
The FIXED/LOWEST handling in __apic_accept_irqs is not as straightforward
as the old kvm_apic_set_irq. Perhaps replace
orig_irr = apic_test_and_set_irr(vector, apic);
if (orig_irr && trig_mode) {
apic_debug("level trig mode repeatedly for vector %d",
vector);
break;
}
if (trig_mode) {
apic_debug("level trig mode for vector %d", vector);
apic_set_vector(vector, apic->regs + APIC_TMR);
} else
apic_clear_vector(vector, apic->regs + APIC_TMR);
kvm_vcpu_kick(vcpu);
With the old
> - if (!apic_test_and_set_irr(vec, apic)) {
> - /* a new pending irq is set in IRR */
> - if (trig)
> - apic_set_vector(vec, apic->regs + APIC_TMR);
> - else
> - apic_clear_vector(vec, apic->regs + APIC_TMR);
> - kvm_vcpu_kick(apic->vcpu);
Note they are slightly different. The first version will update APIC_TMR
even if the IRR was already set, for trig_mode == 0.
Otherwise looks very nice, I've updated Sheng's "KVM: Merge
kvm_ioapic_get_delivery_bitmask into kvm_get_intr_delivery_bitmask",
so please rebase against that.
git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/kvm.git kvm-devel
branch, will push in a few minutes.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with KVM-84 and more than 4 processors
Hi Charles! This mail seems to be somehow related to the bug report of Justin Keogh from 30th Dec 2008. He was able to fix his problem by simply setting CONFIG_KVM=m, but I'm already using modules, so his workaround can't be applied here. Quick question -- does your dmesg output include "loaded kvm module (kvm-84)" [ie. including the version number]? If not, it may be that you're using the module built with your kernel rather than the one built with the kvm release package. This is from my dmesg output: [ 11.983892] loaded kvm module (kvm-84) Best, Matthias -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] Support for device capability
On Wed, Mar 04, 2009 at 10:56:36AM +0800, Sheng Yang wrote:
> On Tuesday 03 March 2009 20:42:07 Marcelo Tosatti wrote:
> > Hi Sheng,
> >
> > On Mon, Mar 02, 2009 at 04:29:27PM +0800, Sheng Yang wrote:
> > > This framework can be easily extended to support device capability, like
> > > MSI/MSI-x.
> > >
> > > Signed-off-by: Sheng Yang
> > > ---
> > > qemu/hw/pci.c | 85
> > > + qemu/hw/pci.h |
> > > 30
> > > 2 files changed, 115 insertions(+), 0 deletions(-)
> > >
> > >
> > > @@ -205,6 +215,15 @@ struct PCIDevice {
> > >
> > > /* Current IRQ levels. Used internally by the generic PCI code. */
> > > int irq_state[4];
> > > +
> > > +/* Device capability configuration space */
> > > +struct {
> > > +int supported;
> > > +uint8_t config[PCI_CAPABILITY_CONFIG_MAX_LENGTH];
> > > +unsigned int start, length;
> > > +PCICapConfigReadFunc *config_read;
> > > +PCICapConfigWriteFunc *config_write;
> > > +} cap;
> > > };
> >
> > Why do you have a copy of the capabilities config space? Why not just
> > access PCIDevice->config directly?
>
> I am not sure upstream would accept which. Separate the logic seems more
> clear
> and easy to accept to me...
You have to maintain two copies of the same data. Whats the point? The
logic can be separate with a unified config space, no?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Consolidate ioapic/ipi interrupt delivery logic.
Use kvm_apic_match_dest() in kvm_get_intr_delivery_bitmask() instead
of duplicating the same code. Use kvm_get_intr_delivery_bitmask() in
apic_send_ipi() to figure out ipi destination instead of reimplementing
the logic.
Signed-off-by: Gleb Natapov
---
arch/ia64/kvm/kvm-ia64.c| 25 -
arch/ia64/kvm/lapic.h |4 +
arch/x86/include/asm/kvm_host.h |2 -
arch/x86/kvm/lapic.c| 114 +++
arch/x86/kvm/lapic.h|2 +
virt/kvm/ioapic.c |5 +-
virt/kvm/ioapic.h | 11 ++--
virt/kvm/irq_comm.c | 82 +---
8 files changed, 90 insertions(+), 155 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 708b1fc..952209a 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1834,20 +1834,21 @@ int kvm_apic_match_logical_addr(struct kvm_lapic *apic,
u8 mda)
return 0;
}
-struct kvm_vcpu *kvm_get_lowest_prio_vcpu(struct kvm *kvm, u8 vector,
- unsigned long bitmap)
+int kvm_apic_compare_prio(struct kvm_vcpu *vcpu1, struct kvm_vcpu *vcpu2)
{
- struct kvm_vcpu *lvcpu = kvm->vcpus[0];
- int i;
-
- for (i = 1; i < kvm->arch.online_vcpus; i++) {
- if (!kvm->vcpus[i])
- continue;
- if (lvcpu->arch.xtp > kvm->vcpus[i]->arch.xtp)
- lvcpu = kvm->vcpus[i];
- }
+ return vcpu1->arch.xtp - vcpu2->arch.xtp;
+}
- return lvcpu;
+int kvm_apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source,
+ int short_hand, int dest, int dest_mode)
+{
+ if (dest_mode == 0) {
+ /* Physical mode. */
+ result = kvm_apic_match_physical_addr(target, dest);
+ } else
+ /* Logical mode. */
+ result = kvm_apic_match_logical_addr(target, dest);
+ return 0;
}
static int find_highest_bits(int *dat)
diff --git a/arch/ia64/kvm/lapic.h b/arch/ia64/kvm/lapic.h
index cbcfaa6..e42109e 100644
--- a/arch/ia64/kvm/lapic.h
+++ b/arch/ia64/kvm/lapic.h
@@ -20,6 +20,10 @@ void kvm_free_lapic(struct kvm_vcpu *vcpu);
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_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source,
+ int short_hand, int dest, int dest_mode);
+int kvm_apic_compare_prio(struct kvm_vcpu *vcpu1, struct kvm_vcpu *vcpu2);
+bool kvm_apic_present(struct kvm_vcpu *vcpu);
int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 dmode, u8 trig);
#endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f0faf58..4627627 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -286,6 +286,7 @@ struct kvm_vcpu_arch {
u64 shadow_efer;
u64 apic_base;
struct kvm_lapic *apic;/* kernel irqchip context */
+ int32_t apic_arb_prio;
int mp_state;
int sipi_vector;
u64 ia32_misc_enable_msr;
@@ -400,7 +401,6 @@ struct kvm_arch{
struct hlist_head irq_ack_notifier_list;
int vapics_in_nmi_mode;
- int round_robin_prev_vcpu;
unsigned int tss_addr;
struct page *apic_access_page;
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index d58268f..5e4dd4f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -260,7 +260,7 @@ static void apic_set_tpr(struct kvm_lapic *apic, u32 tpr)
int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u16 dest)
{
- return kvm_apic_id(apic) == dest;
+ return dest == 0xff || kvm_apic_id(apic) == dest;
}
int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8 mda)
@@ -289,37 +289,34 @@ int kvm_apic_match_logical_addr(struct kvm_lapic *apic,
u8 mda)
return result;
}
-static int apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source,
+int kvm_apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source,
int short_hand, int dest, int dest_mode)
{
int result = 0;
struct kvm_lapic *target = vcpu->arch.apic;
apic_debug("target %p, source %p, dest 0x%x, "
- "dest_mode 0x%x, short_hand 0x%x",
+ "dest_mode 0x%x, short_hand 0x%x\n",
target, source, dest, dest_mode, short_hand);
ASSERT(!target);
switch (short_hand) {
case APIC_DEST_NOSHORT:
- if (dest_mode == 0) {
+ if (dest_mode == 0)
/* Physical mode. */
- if ((dest == 0xFF) || (dest == kvm_apic_id(target)))
- result = 1;
- } else
+ result = kvm_apic_match_physical_addr(target, dest);
+ else
/* Logical mode
[PATCH 2/3] ioapic/msi interrupt delivery consolidation.
ioapic_deliver() and kvm_set_msi() have code duplication. Move
the code into ioapic_deliver_entry() function and call it from
both places.
Signed-off-by: Gleb Natapov
---
virt/kvm/ioapic.c | 60 +++
virt/kvm/ioapic.h |4 ++-
virt/kvm/irq_comm.c | 32 +++
3 files changed, 37 insertions(+), 59 deletions(-)
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index 94f6312..b71c044 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -142,53 +142,57 @@ static void ioapic_write_indirect(struct kvm_ioapic
*ioapic, u32 val)
}
}
-static int ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
+int ioapic_deliver_entry(struct kvm *kvm, union kvm_ioapic_redirect_entry *e)
{
- union kvm_ioapic_redirect_entry entry = ioapic->redirtbl[irq];
DECLARE_BITMAP(deliver_bitmask, KVM_MAX_VCPUS);
- struct kvm_vcpu *vcpu;
- int vcpu_id, r = -1;
-
- ioapic_debug("dest=%x dest_mode=%x delivery_mode=%x "
-"vector=%x trig_mode=%x\n",
-entry.fields.dest, entry.fields.dest_mode,
-entry.fields.delivery_mode, entry.fields.vector,
-entry.fields.trig_mode);
+ int i, r = -1;
- /* Always delivery PIT interrupt to vcpu 0 */
-#ifdef CONFIG_X86
- if (irq == 0)
- __set_bit(0, deliver_bitmask);
- else
-#endif
- kvm_get_intr_delivery_bitmask(ioapic, &entry, deliver_bitmask);
+ kvm_get_intr_delivery_bitmask(kvm, e, deliver_bitmask);
if (find_first_bit(deliver_bitmask, KVM_MAX_VCPUS) >= KVM_MAX_VCPUS) {
ioapic_debug("no target on destination\n");
- return 0;
+ return r;
}
- while ((vcpu_id = find_first_bit(deliver_bitmask, KVM_MAX_VCPUS))
+ while ((i = find_first_bit(deliver_bitmask, KVM_MAX_VCPUS))
< KVM_MAX_VCPUS) {
- __clear_bit(vcpu_id, deliver_bitmask);
- vcpu = ioapic->kvm->vcpus[vcpu_id];
+ struct kvm_vcpu *vcpu = kvm->vcpus[i];
+ __clear_bit(i, deliver_bitmask);
if (vcpu) {
if (r < 0)
r = 0;
- r += kvm_apic_set_irq(vcpu,
- entry.fields.vector,
- entry.fields.trig_mode,
- entry.fields.delivery_mode);
+ r += kvm_apic_set_irq(vcpu, e->fields.vector,
+ e->fields.delivery_mode,
+ e->fields.trig_mode);
} else
ioapic_debug("null destination vcpu: "
"mask=%x vector=%x delivery_mode=%x\n",
-entry.fields.deliver_bitmask,
-entry.fields.vector,
-entry.fields.delivery_mode);
+e->fields.deliver_bitmask,
+e->fields.vector, e->fields.delivery_mode);
}
return r;
}
+static int ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
+{
+ union kvm_ioapic_redirect_entry entry = ioapic->redirtbl[irq];
+
+ ioapic_debug("dest=%x dest_mode=%x delivery_mode=%x "
+"vector=%x trig_mode=%x\n",
+entry.fields.dest, entry.fields.dest_mode,
+entry.fields.delivery_mode, entry.fields.vector,
+entry.fields.trig_mode);
+
+#ifdef CONFIG_X86
+ /* Always delivery PIT interrupt to vcpu 0 */
+ if (irq == 0) {
+ entry.fields.dest_mode = 0; /* Physical mode. */
+ entry.fields.dest_id = ioapic->kvm->vcpus[0]->vcpu_id;
+ }
+#endif
+ return ioapic_deliver_entry(ioapic->kvm, &entry);
+}
+
int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level)
{
u32 old_irr = ioapic->irr;
diff --git a/virt/kvm/ioapic.h b/virt/kvm/ioapic.h
index c8032ab..bedeea5 100644
--- a/virt/kvm/ioapic.h
+++ b/virt/kvm/ioapic.h
@@ -70,8 +70,8 @@ void kvm_ioapic_update_eoi(struct kvm *kvm, int vector, int
trigger_mode);
int kvm_ioapic_init(struct kvm *kvm);
int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level);
void kvm_ioapic_reset(struct kvm_ioapic *ioapic);
-void kvm_get_intr_delivery_bitmask(struct kvm_ioapic *ioapic,
+void kvm_get_intr_delivery_bitmask(struct kvm *kvm,
union kvm_ioapic_redirect_entry *entry,
unsigned long *deliver_bitmask);
-
+int ioapic_deliver_entry(struct kvm *kvm, union kvm_ioapic_redirect_entry *e);
#endif
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index b37126c..a25eb23 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -43
[PATCH 0/3] ioapic/lapic/msi cleanup
There are many code/logic duplications throughout ioapic/lapic/msi device emulation. Try to consolidate as much code as possible. The patch series is on top of Sheng Yang's patch: KVM: Merge kvm_ioapic_get_delivery_bitmask into kvm_get_intr_delivery_bitmask --- Gleb Natapov (3): Consolidate ioapic/ipi interrupt delivery logic. ioapic/msi interrupt delivery consolidation. Make kvm_apic_set_irq() deliver all kinds of interrupts. arch/ia64/include/asm/kvm_host.h |1 arch/ia64/kvm/kvm-ia64.c | 33 - arch/ia64/kvm/lapic.h|6 +- arch/x86/include/asm/kvm_host.h |2 - arch/x86/kvm/lapic.c | 147 ++ arch/x86/kvm/lapic.h |4 + virt/kvm/ioapic.c| 89 +-- virt/kvm/ioapic.h| 13 ++- virt/kvm/irq_comm.c | 109 +++- 9 files changed, 151 insertions(+), 253 deletions(-) -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Make kvm_apic_set_irq() deliver all kinds of interrupts.
Get rid of ioapic_inj_irq() and ioapic_inj_nmi() functions.
Signed-off-by: Gleb Natapov
---
arch/ia64/include/asm/kvm_host.h |1 -
arch/ia64/kvm/kvm-ia64.c |8
arch/ia64/kvm/lapic.h|2 +-
arch/x86/kvm/lapic.c | 33 ++-
arch/x86/kvm/lapic.h |2 +-
virt/kvm/ioapic.c| 40 ++
virt/kvm/irq_comm.c |1 +
7 files changed, 36 insertions(+), 51 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 4542651..5608488 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -585,7 +585,6 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu);
int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run);
void kvm_sal_emul(struct kvm_vcpu *vcpu);
-static inline void kvm_inject_nmi(struct kvm_vcpu *vcpu) {}
#endif /* __ASSEMBLY__*/
#endif
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 076b00d..708b1fc 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -292,13 +292,13 @@ static void vcpu_deliver_ipi(struct kvm_vcpu *vcpu,
uint64_t dm,
{
switch (dm) {
case SAPIC_FIXED:
- kvm_apic_set_irq(vcpu, vector, 0);
+ kvm_apic_set_irq(vcpu, vector, dm, 0);
break;
case SAPIC_NMI:
- kvm_apic_set_irq(vcpu, 2, 0);
+ kvm_apic_set_irq(vcpu, 2, dm, 0);
break;
case SAPIC_EXTINT:
- kvm_apic_set_irq(vcpu, 0, 0);
+ kvm_apic_set_irq(vcpu, 0, dm, 0);
break;
case SAPIC_INIT:
case SAPIC_PMI:
@@ -1811,7 +1811,7 @@ void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
put_cpu();
}
-int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig)
+int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 dmode, u8 trig)
{
struct vpd *vpd = to_host(vcpu->kvm, vcpu->arch.vpd);
diff --git a/arch/ia64/kvm/lapic.h b/arch/ia64/kvm/lapic.h
index 6d6cbcb..cbcfaa6 100644
--- a/arch/ia64/kvm/lapic.h
+++ b/arch/ia64/kvm/lapic.h
@@ -20,6 +20,6 @@ void kvm_free_lapic(struct kvm_vcpu *vcpu);
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_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 dmode, u8 trig);
#endif
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index afc59b2..d58268f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -196,20 +196,30 @@ int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvm_lapic_find_highest_irr);
-int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig)
+static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,
+int vector, int level, int trig_mode);
+
+int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 dmode, u8 trig)
{
struct kvm_lapic *apic = vcpu->arch.apic;
+ int lapic_dmode;
- if (!apic_test_and_set_irr(vec, apic)) {
- /* a new pending irq is set in IRR */
- if (trig)
- apic_set_vector(vec, apic->regs + APIC_TMR);
- else
- apic_clear_vector(vec, apic->regs + APIC_TMR);
- kvm_vcpu_kick(apic->vcpu);
- return 1;
+ switch(dmode) {
+ case IOAPIC_LOWEST_PRIORITY:
+ lapic_dmode = APIC_DM_LOWEST;
+ break;
+ case IOAPIC_FIXED:
+ lapic_dmode = APIC_DM_FIXED;
+ break;
+ case IOAPIC_NMI:
+ lapic_dmode = APIC_DM_NMI;
+ break;
+ default:
+ printk(KERN_DEBUG"Ignoring delivery mode %d\n", dmode);
+ return 0;
+ break;
}
- return 0;
+ return __apic_accept_irq(apic, lapic_dmode, vec, 1, trig);
}
static inline int apic_find_highest_isr(struct kvm_lapic *apic)
@@ -364,12 +374,14 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
delivery_mode,
break;
case APIC_DM_NMI:
+ result = 1;
kvm_inject_nmi(vcpu);
kvm_vcpu_kick(vcpu);
break;
case APIC_DM_INIT:
if (level) {
+ result = 1;
if (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE)
printk(KERN_DEBUG
"INIT on a runnable vcpu %d\n",
@@ -386,6 +398,7 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
delivery_mode,
apic_debug("SIPI to vcpu %d vector 0x%02x\n",
vcpu->vcpu_id, ve
kvm-84 kernel panic
Hi, i had serveral kernel panics in the last days on a DELL R300. First i had ubuntu 8.10 running with latest kvm compiled. the panic looked like this: http://memic.paniert.org/screen.png The impi log looks like this 2d | 02/19/2009 | 02:54:31 | Processor #0x0d | Transition to Non-recoverable 2e | 02/19/2009 | 02:54:32 | Processor #0x60 | IERR | Asserted 32 | 02/19/2009 | 14:55:52 | Processor #0x0d | Transition to Non-recoverable 33 | 02/24/2009 | 23:00:14 | Processor #0x0d | Transition to Non-recoverable 37 | 02/25/2009 | 22:58:02 | Processor #0x0d | Transition to Non-recoverable 38 | 03/03/2009 | 13:59:03 | Processor #0x0d | Transition to Non-recoverable 39 | 03/03/2009 | 17:41:34 | Processor #0x0d | Transition to Non-recoverable 3a | 03/04/2009 | 07:41:02 | Processor #0x0d | Transition to Non-recoverable 3b | 03/04/2009 | 11:03:23 | Processor #0x0d | Transition to Non-recoverable 3c | 03/04/2009 | 11:03:26 | Processor #0x60 | IERR | Asserted 3d | 03/04/2009 | 11:08:16 | Processor #0x60 | IERR | Deasserted Right now i have fedora 10 as host system running, with the newest kvm version. My CPU is Intel(R) Xeon(R) CPU X3363 @ 2.83GHz Quadcore. I have 2 Windows 2003 Enterprise Domains running at almost no load. Im not sure when to panic happens but it think its reproducable if the guest systems are under load. What can i do to get more debug information? Thx so far.. Johannes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm: fix irq 0 assignment
On Wed, Mar 04, 2009 at 03:54:27PM +0800, Sheng Yang wrote: > Shouldn't update assigned irq if host irq is 0, which means > uninitialized or don't support INTx. Is that generally true? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm: fix irq 0 assignment
On Wednesday 04 March 2009 17:58:31 Sheng Yang wrote: > On Wednesday 04 March 2009 17:53:52 Chris Wedgwood wrote: > > On Wed, Mar 04, 2009 at 03:54:27PM +0800, Sheng Yang wrote: > > > Shouldn't update assigned irq if host irq is 0, which means > > > uninitialized or don't support INTx. > > > > Is that generally true? > > Host irq 0 is reserved for PIT timer, at least for x86. Or in some other condition it would be used for pci/pcie device? And please notice that currently we only support assign with x86 and IA64. (I really feel there is some reason for you ask. :) ) -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm: fix irq 0 assignment
On Wednesday 04 March 2009 17:53:52 Chris Wedgwood wrote: > On Wed, Mar 04, 2009 at 03:54:27PM +0800, Sheng Yang wrote: > > Shouldn't update assigned irq if host irq is 0, which means > > uninitialized or don't support INTx. > > Is that generally true? Host irq 0 is reserved for PIT timer, at least for x86. -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
Ryan Harper wrote: * Uri Lublin [2009-03-01 13:10]: Ryan, Sorry for the late response. KVM-autotest is a test framework for kvm, based on autotest (http://autotest.kernel.org). I've been digging into kvm_runtest_2 and have some feedback, but first to say, runtest_2 is huge cleanup and simplification from runtest, so thanks. Now for some comments: - kvm_tests.cfg has a decent learning curve to wrap your head around. It would have been useful to have some debugging that would dump out what rules were filtering out guests... the dependencies aren't always easy to find. My first experience with the dep hunt is just changing 'only qcow2' in fc8_quick to raw and getting no output from kvm_config.py. Turns out, that 'raw' has a smp2 requirement ... that sort of filtering could be displayed with debugging output making configuration changes easier. I agree, we need to add some debug messages to kvm_config.py. The smp - raw connection, of course, should not have left in the configuration file. It was just us testing the code. - documentation of keywords and structure would be nice, explaining what -variant , only and @ are doing for you, etc. Please read http://kvm.qumranet.com/kvmwiki/RegressionTests/ConfigFile2 - it seems like the definition and rules ought to be separate from the last section which defines which tests to run (the fc8_quick area), so adding something as simple as include support to kvm_config.py would be sufficient to support a common definition file but different testing rules. An include support is one way to do it. We thought of a different way, which is to add rules from the control file. So the control file would pick the test-list it wants to run. Your suggestion is simpler but you need both a config file and a control file to change the test-list. We need to change only the control file. - kvm_runtest_2 as mentioned doesn't mess with your host networking and relies on -net user and redir, would be good to plumb through -net tap support that can be configured instead of always using -net user We want to add -net tap support, as that is what users usually use. kvm_runtest does exactly that (a part of kvm_host.cfg). The drawbacks of tap are (among others): - One must run tests as root, or play with sudo/chmod (True for /dev/kvm, but simpler) - You have to a have a dhcpd around. kvm_runtest by default runs a local dhcpd to serve kvm guests (part of setup/cleanup tests). - A bit more difficult to configure. - make -vnc parameter config/optional Agreed I noticed the references to the setup isos for windows that presumbly install cygwin telnetd/sshd, are those available? if the isos themselves aren't, if the build instructions are, that would be very useful. You are right. We do have an installation iso images for telnetd/sshd. I did not want to commit iso images. Also, I am not sure about licensing, and I prefer that we would generate them on the user machine. We'll add the build instructions to the wiki. - guest install wizard using md5sum region matching ... ouch. This is quite fickle. I've seen different kvms generate different md5sum for the same region a couple of times. I know distributing screenshots of certain OSes is a grey area, but it would be nice to plumb through screenshot comparison and make that configurable. FWIW, I'll probably look at pulling the screenshot comparison bits from kvmtest and getting that integrated in kvm_runtest_2. Creating a step file is not as easy as it seems, exactly for that reason. One has to pick a part of the screenshot that only available when input is expected and that would be consistent. We were thinking of replacing the md5sum with a tiny compressed image of the part of the image that was picked. We had two other implementation for guest-wizard, one which only compares two/three consecutive screendumps (problems with e.g. clock ticking), and one similar to kvmtest. The kvmtest way is to let the user create his/her own screendumps to be used later. I did not want to add so many screendumps images to the repository. Step-Maker keeps the images it uses, so we can compare them upon failure. Step-Editor lets the user to change a single barrier_2 step (or more) by looking at the original image and picking a different area. - kvm_runtest_2 looks a lot more like a regular autotest test, which is a Good Thing(TM). There are still some things that would prevent it going upstream autotest (which I assume is the long term goal) You assume correctly. - a lot of the ssh and scp work to copy autotest client into a guest is already handled by autoserv That is true, but we want to be able to run it as client test too. That way a user does not have to install the server to run kvm tests on his/her machine. - vm.py has a lot of infrastructure that should be integrated into autotest/server/kvm.py or possibly client-side common code to support the next comment In the long term,
