Re: [PATCH 6/8]kvm/ia64: Make pmt table be able to hold physical mmio entries.
* On Monday 29 Sep 2008 10:56:58 Zhang, Xiantao wrote:
> From c459cae4b89b445a2b85be915b269676b6ff394f Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Sat, 27 Sep 2008 12:52:35 +0800
> Subject: [PATCH] kvm/ia64: Make pmt table be able to hold physical mmio
> entries.
>
> Don't try to do put_page once the entries are mmio.
> Set the tag to indicate the mmio space for vmm setting
> TLB's memory attribute.
> Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
> ---
> arch/ia64/kvm/kvm-ia64.c | 20 +---
> 1 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
> index a6cf719..20622d6 100644
> --- a/arch/ia64/kvm/kvm-ia64.c
> +++ b/arch/ia64/kvm/kvm-ia64.c
> @@ -1437,17 +1437,23 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
> int user_alloc)
> {
> unsigned long i;
> - struct page *page;
> + unsigned long pfn;
> int npages = mem->memory_size >> PAGE_SHIFT;
> struct kvm_memory_slot *memslot = &kvm->memslots[mem->slot];
> unsigned long base_gfn = memslot->base_gfn;
> -
> for (i = 0; i < npages; i++) {
Please keep that line break; it'll be tougher to read without that.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of pci passthrough work?
Please keep me in the CC to get faster replies. * On Monday 29 Sep 2008 06:39:26 Thomas Fjellstrom wrote: > > > > Yes, currently you need VT-d support in hardware to assign device. > > > > > > So I take it the PV-DMA (or pv-dma doesn't do what I think it does...) > > > or the other 1:1 device pass through work isn't working right now? > > > > pvdma does work, but the most recent patches aren't yet published (I > > should do that). It will work for simple devices. > > > > 1:1 will also work. > > Once the trees are updated? pvdma, yes. I don't have the 1:1 patches in my tree as of now. Andrea maintains those patches. > > > It's something I'd really like to use, but I don't have access to a > > > platform with a hardware iommu. Though I might be able to pick up a > > > replacement board for my new server with the SB750 southbridge which > > > supposedly has AMD's new iommu hardware in it, but I haven't seen any > > > evidence that kvm or linux supports it. > > > > Linux 2.6.27 onwards supports AMD IOMMU. kvm (and device assignment) > > support for AMD IOMMU doesn't exist yet, but work is planned to start > > soon. > > What does the kernel supporting it help a person wanting to use it to pass > through devices to guests if kvm doesn't support it? Also, what would the > kernel use it for in that case? That's right; that was just to give you an idea of how things are progressing. > Its rather hard to find the patches from before I joined the list, most > archives don't keep attachments. Sure; look for an update next week. > Thanks for the heads up, and all the work on this stuff :) You're welcome and it's always good to hear from users. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2143498 ] FreeBSD fails to reboot
Bugs item #2143498, was opened at 2008-10-02 22:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2143498&group_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: Matt Lehner (mlehner) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD fails to reboot Initial Comment: Xeon E5430, ubuntu 8.04 x86_64, currently kvm-62. Reports of same issue in kvm76: https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/239107 Host kernel: 2.6.24-19 Guest: FreeBSD 6.2, i386 and amd64 Problem: FreeBSD will start normally as a guest OS. When a "reboot" is issued to the guest, it will not come back up without destroying the guest, and then starting it again. Screenshots from a reboot: http://lehner.pair.com/screenshot1.png Note that the drive is listed. http://lehner.pair.com/screenshot2.png In the second screenshot, the drive should be listed right after the Timecounters lines. If the guest is destroyed at that point, and restarted it will come up fine. This can be reproduced 100% of the time. Happens both when using a file or a partition for the guest OS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2143498&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] fix build breakage of qemu/kvm on ia64
Thanks Jes! Acked-by : Xiantao zhang <[EMAIL PROTECTED]> -Original Message- From: Jes Sorensen [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2008 11:37 PM To: Avi Kivity; [EMAIL PROTECTED]; kvm@vger.kernel.org; Zhang, Xiantao Subject: [patch] fix build breakage of qemu/kvm on ia64 Hi, This one cleans up some problems with how the ia64 headers declared 'env' and also included stdio.h in cpu.h. It builds and still boots kvm on my test system :-) Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] Patchset to enable vt-d support for kvm/ia64.
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> +
>> +/* This should be called with the kvm->lock mutex held */
>> +void kvm_set_irq(struct kvm *kvm, int irq, int level) +{
>> +/* Not possible to detect if the guest uses the PIC or the
>> + * IOAPIC. So set the bit in both. The guest will ignore
>> + * writes to the unused one.
>> + */
>> +kvm_ioapic_set_irq(kvm->arch.vioapic, irq, level); +#ifdef X86
>> +kvm_pic_set_irq(pic_irqchip(kvm), irq, level);
>> +#endif
>> +}
>>
>
> Will non-x86, non-ia64 archs survive this?
So far, I only see x86 and ia64 can share this code, since it is
splitted from x86 arch. Currenlty non-x86 and non-ia64 archs shouldn't
compile in this part.
Xiantao
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unhandled vm exit: 0x80000021 vcpu_id 0
On Fri, Oct 03, 2008 at 12:16:20AM +0200, [EMAIL PROTECTED] wrote: > > Hi, > I understand the "particularity" (checkpoint) of this case. Hi Pier Thanks for your understanding. :) > > Any way, in the attachment the dmesg log and the output of the dmesg > command. But it's strange that I almost can't see anything correlated with kvm in the log. If you built kvm as a modules(I suppose you did it because you tried many versions), at least something like "load kvm module xxx" should appear(and Windows always trig a apic write error before Jan's patch make them slience). Is this the dmesg when the error was happening? -- regards Yang, Sheng > > thanks for your helpfulness. > > Regards. > > Sheng Yang wrote: > > On Mon, Sep 29, 2008 at 6:18 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED] > it> wrote: > > > >> Hi, > >> I have successfully installed windows XP SP2 on kvm. After the > >> installation I have launched the setup of "Checkpoint - Pointsec" > for > >> the entire disk encryption. > >> > > > > Hi Pier > > > > Can you issue a bug for this? But sadly "Checkpoint" is a commercial > > software, we may not deal with it directly and immediately. > > > > > >> The first step of installation was run successfully, but when the > >> system reboots and "Pointsec" loads the initial code, the following > >> error happens: > >> > == > >> unhandled vm exit: 0x8021 vcpu_id 0 > >> rax 0007 rbx 1490 rcx rdx > >> 19a0 > >> rsi rdi rsp 0080 rbp > >> 96bf > >> r8 r9 r10 r11 > >> > >> r12 r13 r14 r15 > >> > >> rip 002a rflags 00023202 > >> cs 14a2 (/ p 0 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) > >> ds 19a0 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > >> es 1a31 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > >> ss 1a29 (/ p 0 dpl 0 db 0 s 0 type 1 l 0 g 0 avl 0) > >> fs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > >> gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > >> tr 0058 (00201ffa/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > >> ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl > 0) > >> gdt 20/1dd8 > >> idt 201df0/188 > >> cr0 8019 cr2 0 cr3 144 cr4 0 cr8 0 efer 0 > >> > > > > What's this... CR0.PE clear, CR0.PG set... And segment register also > > strange. May be some real emulation wrong... > > > > > >> Aborted > >> > == > >> I am able to boot this system (image) using qemu (with kqemu > enabled > >> for user code), but not using kvm. > >> I have also tried with the options: -no-kvm-irqchip -no-kvm-pit - > no- > >> acpi without success. Only the -no-kvm option works. > >> I have tried these kvm releases: from 65 to 76; and these kernel > >> (vanilla) releases: from 2.6.23.1 to 2.6.26.5. > >> > > > > Thanks for your patient... > > > >> My computer is a Dell D630 equipped with Intel(R) Core(TM)2 Duo CPU > >> T7300 @ 2.00GHz > >> The HOST Linux distributions used are: Fedora 8/9 for i386, and > Fedora > >> 9 for x86_64. > >> > > > > Can you show dmesg as well? That's also helps. > > > > > > > > > > > > ___ > > Con Tiscali Adsl 8 Mega navighi SENZA LIMITI e GRATIS PER I PRIMI TRE MESI. > In seguito paghi solo ??? 19,95 al mese. Attivala subito, l?offerta è valida > fino al 02/10/2008! http://abbonati.tiscali.it/promo/adsl8mega/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138166 ] Vista guest fails to start on kvm-76
Bugs item #2138166, was opened at 2008-09-30 08:39 Message generated for change (Comment added) made by johnrrousseau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Vista guest fails to start on kvm-76 Initial Comment: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Build: kvm-76 Host kernel: 2.6.26.3-29.fc9.x86_64 Host arch: x86_64 Guest: Windows Vista Ultimate 64-bit QEMU command: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -std-vga -full-screen -smp 2 I've been running this guest on this host with kvm-75 without difficulty. kvm-76, built the same way that kvm-75 was (and on the same machine), fails to start my guest. The guest window is up, but the guest fails to complete startup. Command line output is: kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists set_vram_mapping failed kvm: get_dirty_pages returned -2 The last line repeats hundreds of times. -- >Comment By: John Rousseau (johnrrousseau) Date: 2008-10-02 20:06 Message: kvm-2646c5.tar.gz: Worked fine kvm-d558461.tar.gz: Failed (showed this bug) I've never used git before, but if you teach me to fish... I installed git, pulled the userspace and kernel trees, built kvm-75 and kvm-76 and got the expected results, but when I did a bisect on kvm-75 (good) and kvm-76 (bad) I kept getting sparse trees that I couldn't build. "configure" among other things was missing. What am I doing wrong? Also, what should I be syncing my kernel tree to when I am bisecting the userspace tree? Thanks. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-10-02 12:27 Message: Are you using git? If so, can you bisect to find out who the culprit is? If not, I've managed to archive two strategic commits you should try: http://glommer.net/kvm-2646c5.tar.gz and http://glommer.net/kvm-d558461.tar.gz please report success or failure with them thanks! -- Comment By: John Rousseau (johnrrousseau) Date: 2008-10-02 11:48 Message: I applied the patch to kvm-76 and ran into basically the same problem. The guest still hung during boot and I got the plume of kvm: get_dirty_pages returned -2 errors, but the first message "kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists" wasn't displayed. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-10-02 09:01 Message: can you please test the patch at http://glommer.net/band-aid.patch ? -- Comment By: Brian Jackson (iggy_cav) Date: 2008-09-30 10:06 Message: This was reported on the mailing list. It's a problem with sdl output. Not specific to any guest. Until the problem is fixed, I'd suggest using vnc output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Refactor AIO to allow multiple AIO implementations
Ryan Harper wrote: Results: These results are with the patch series applied to KVM (plus a small KVM only change -- KVM patches forthcoming). Is the above "KVM only change" a kernel-side kvm patch? If so could you provide a pointer? Didn't see anything related AFAICT in kvm.git since then. Thanks, -john -- [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unhandled vm exit: 0x80000021 vcpu_id 0
Hi, I understand the "particularity" (checkpoint) of this case. Any way, in the attachment the dmesg log and the output of the dmesg command. thanks for your helpfulness. Regards. Sheng Yang wrote: > On Mon, Sep 29, 2008 at 6:18 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED] it> wrote: > >> Hi, >> I have successfully installed windows XP SP2 on kvm. After the >> installation I have launched the setup of "Checkpoint - Pointsec" for >> the entire disk encryption. >> > > Hi Pier > > Can you issue a bug for this? But sadly "Checkpoint" is a commercial > software, we may not deal with it directly and immediately. > > >> The first step of installation was run successfully, but when the >> system reboots and "Pointsec" loads the initial code, the following >> error happens: >> == >> unhandled vm exit: 0x8021 vcpu_id 0 >> rax 0007 rbx 1490 rcx rdx >> 19a0 >> rsi rdi rsp 0080 rbp >> 96bf >> r8 r9 r10 r11 >> >> r12 r13 r14 r15 >> >> rip 002a rflags 00023202 >> cs 14a2 (/ p 0 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) >> ds 19a0 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) >> es 1a31 (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) >> ss 1a29 (/ p 0 dpl 0 db 0 s 0 type 1 l 0 g 0 avl 0) >> fs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) >> gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) >> tr 0058 (00201ffa/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) >> ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) >> gdt 20/1dd8 >> idt 201df0/188 >> cr0 8019 cr2 0 cr3 144 cr4 0 cr8 0 efer 0 >> > > What's this... CR0.PE clear, CR0.PG set... And segment register also > strange. May be some real emulation wrong... > > >> Aborted >> == >> I am able to boot this system (image) using qemu (with kqemu enabled >> for user code), but not using kvm. >> I have also tried with the options: -no-kvm-irqchip -no-kvm-pit - no- >> acpi without success. Only the -no-kvm option works. >> I have tried these kvm releases: from 65 to 76; and these kernel >> (vanilla) releases: from 2.6.23.1 to 2.6.26.5. >> > > Thanks for your patient... > >> My computer is a Dell D630 equipped with Intel(R) Core(TM)2 Duo CPU >> T7300 @ 2.00GHz >> The HOST Linux distributions used are: Fedora 8/9 for i386, and Fedora >> 9 for x86_64. >> > > Can you show dmesg as well? That's also helps. > > ___ Con Tiscali Adsl 8 Mega navighi SENZA LIMITI e GRATIS PER I PRIMI TRE MESI. In seguito paghi solo € 19,95 al mese. Attivala subito, l?offerta è valida fino al 02/10/2008! http://abbonati.tiscali.it/promo/adsl8mega/ dmesg.tgz Description: GNU Zip compressed data
Is it ok to compile kvm with gcc-4.1.2?
Hi, Is it ok to use gcc-4.1.2 to compile kvm module and utility tools now? Or is gcc-3.x.x still required? Simon -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm-autotest results for kvm-76
Hello, We are testing 5 guest OSes, each with some qemu/kvm command line options and using some tests. For example user-irq means '-no-kvm-irqchip -no-kvm-pit'. Regards, Uri. kvm_setup GOOD kvm_install GOOD kvm_guest_install.fc8-i386-1024mGOOD kvm_test_boot.fc8-i386-1024mGOOD kvm_test_reboot.fc8-i386-1024m GOOD kvm_test_migration.fc8-i386-1024m GOOD kvm_test_boot.fc8-i386-user-irq GOOD kvm_test_reboot.fc8-i386-user-irq FAIL kvm_test_migration.fc8-i386-user-irqGOOD kvm_test_boot.fc8-i386-smp4 GOOD kvm_test_reboot.fc8-i386-smp4 FAIL kvm_test_migration.fc8-i386-smp4GOOD kvm_guest_install.dsl-4.2.5 GOOD kvm_test_boot.dsl-4.2.5 GOOD kvm_test_reboot.dsl-4.2.5 GOOD kvm_test_migration.dsl-4.2.5GOOD kvm_test_boot.dsl-4.2.5-user-irqGOOD kvm_test_reboot.dsl-4.2.5-user-irq GOOD kvm_test_migration.dsl-4.2.5-user-irq GOOD kvm_test_boot.dsl-4.2.5-smp4GOOD kvm_test_reboot.dsl-4.2.5-smp4 GOOD kvm_test_migration.dsl-4.2.5-smp4 GOOD kvm_guest_install.centos5-64GOOD kvm_test_boot.centos5-64GOOD kvm_test_reboot.centos5-64 GOOD kvm_test_migration.centos5-64 GOOD kvm_test_boot.centos5-64-user-irq GOOD kvm_test_reboot.centos5-64-user-irq GOOD kvm_test_migration.centos5-64-user-irq GOOD kvm_test_boot.centos5-64-smp4 GOOD kvm_test_reboot.centos5-64-smp4 FAIL kvm_test_migration.centos5-64-smp4 FAIL kvm_guest_install.winxp GOOD kvm_test_boot.winxp GOOD kvm_test_reboot.winxp GOOD kvm_test_migration.winxpGOOD kvm_test_boot.winxp-user-irqGOOD kvm_test_reboot.winxp-user-irq GOOD kvm_test_migration.winxp-user-irq GOOD kvm_test_boot.winxp-smp4GOOD kvm_test_reboot.winxp-smp4 GOOD kvm_test_migration.winxp-smp4 GOOD kvm_guest_install.openSUSE11-32 GOOD kvm_test_boot.openSUSE11-32 GOOD kvm_test_reboot.openSUSE11-32 GOOD kvm_test_migration.openSUSE11-32GOOD kvm_test_boot.openSUSE11-32-user-irqGOOD kvm_test_reboot.openSUSE11-32-user-irq GOOD kvm_test_migration.openSUSE11-32-user-irq GOOD kvm_test_boot.openSUSE11-32-smp4GOOD kvm_test_reboot.openSUSE11-32-smp4 GOOD kvm_test_migration.openSUSE11-32-smp4 GOOD kvm_cleanup GOOD GOOD -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
thread/core siblings info for guests
Avi, There are some OSes like windows server which impose licensing restriction on number of cpus. These licensing restrictions are based on number of packages/sockets. And look into the cupid data to decide which cpus are thread siblings, core siblings and packages siblings. With current KVM/Qemu implementation it is hiding all this cupid information from the guests. So guest sees each cpu as a single package. And the license restrictions inside the OS is limiting no of cpus the guest can run. These cupid bits should be exposed to the guest so that the OS would see the thread or core sibling information correctly to utilize more cpus. Is anybody is working on this? Thanks & Regards, Nitin Linux Open Source Technology Center, Intel Corporation The Mind is like a parachute; it works much better when it's open. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Avi Kivity wrote: > Farkas Levente wrote: >> ok i don't know any other solution so >> - install kvm-71 to the host >> - install a guest mandrake-10 truly minimal install into file image >> - upgrade to kvm-76 and the guest no longer boot. >> so i've uploaded it for you into: >> ftp://ftp.bppiac.hu/mandrake.img.bz2 >> (this is the bzip-ed image:-) >> can you try to boot this image with kvm-76 (or anything later than >> kvm-71)? >> > > Just ran this on my desktop, it booted fine... getting more and more strange:-( ok which disto, kernel, etc.. could you test in with a minimal fully updated centos-5 x86_64 intel proc with these rpms (of course the latest kernel-2.6.18-92.1.13.el5): http://www.lfarkas.org/linux/packages/centos/5/x86_64/kmod-kvm-2.6.18-92.1.13.el5-76-1.x86_64.rpm http://www.lfarkas.org/linux/packages/centos/5/x86_64/kmod-kvm-76-1.x86_64.rpm http://www.lfarkas.org/linux/packages/centos/5/x86_64/kvm-76-1.x86_64.rpm what else can be different? just the distro and the kernel or...? -- Levente "Si vis pacem para bellum!" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] Fix guest shared interrupt with in-kernel irqchip
How about this one? Still untested.
--
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Fri, 3 Oct 2008 00:07:20 +0800
Subject: [PATCH 1/1] KVM: Fix guest shared interrupt with in-kernel irqchip
Derived from Avi's suggestion, now every call of kvm_set_irq() should offer
a irq_source_id, which is allocated by kvm_request_irq_source_id(). We based
on irq_source_id to identify irq source and implement logical OR for shared
level interrupts.
The allocated irq_source_id can be freed by kvm_free_irq_source_id().
Now we support 32 different irq sources at most.
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/i8254.c | 11 +--
arch/x86/kvm/i8254.h |1 +
arch/x86/kvm/irq.c | 44 +---
arch/x86/kvm/irq.h |5 -
arch/x86/kvm/x86.c | 26 +++---
include/asm-x86/kvm_host.h |3 +++
include/linux/kvm_host.h |1 +
7 files changed, 78 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6144d3f..392089c 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -545,6 +545,12 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm)
if (!pit)
return NULL;
+ mutex_lock(&kvm->lock);
+ pit->irq_source_id = kvm_request_irq_source_id(kvm);
+ mutex_unlock(&kvm->lock);
+ if (pit->irq_source_id < 0)
+ return NULL;
+
mutex_init(&pit->pit_state.lock);
mutex_lock(&pit->pit_state.lock);
spin_lock_init(&pit->pit_state.inject_lock);
@@ -587,6 +593,7 @@ void kvm_free_pit(struct kvm *kvm)
mutex_lock(&kvm->arch.vpit->pit_state.lock);
timer = &kvm->arch.vpit->pit_state.pit_timer.timer;
hrtimer_cancel(timer);
+ kvm_free_irq_source_id(kvm, kvm->arch.vpit->irq_source_id);
mutex_unlock(&kvm->arch.vpit->pit_state.lock);
kfree(kvm->arch.vpit);
}
@@ -598,8 +605,8 @@ static void __inject_pit_timer_intr(struct kvm *kvm)
int i;
mutex_lock(&kvm->lock);
- kvm_set_irq(kvm, 0, 1);
- kvm_set_irq(kvm, 0, 0);
+ kvm_set_irq(kvm, 0, 1, kvm->arch.vpit->irq_source_id);
+ kvm_set_irq(kvm, 0, 0, kvm->arch.vpit->irq_source_id);
mutex_unlock(&kvm->lock);
/*
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index e436d49..4178022 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -44,6 +44,7 @@ struct kvm_pit {
struct kvm_io_device speaker_dev;
struct kvm *kvm;
struct kvm_kpit_state pit_state;
+ int irq_source_id;
};
#define KVM_PIT_BASE_ADDRESS 0x40
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 8c1b9c5..6d8eaef 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -101,14 +101,22 @@ void __kvm_migrate_timers(struct kvm_vcpu *vcpu)
}
/* This should be called with the kvm->lock mutex held */
-void kvm_set_irq(struct kvm *kvm, int irq, int level)
+void kvm_set_irq(struct kvm *kvm, int irq, int level, int irq_source_id)
{
+ unsigned long *irq_state = (unsigned long *)&kvm->arch.irq_states[irq];
+
+ /* Logical OR for level trig interrupt */
+ if (level)
+ set_bit(irq_source_id, irq_state);
+ else
+ clear_bit(irq_source_id, irq_state);
+
/* Not possible to detect if the guest uses the PIC or the
* IOAPIC. So set the bit in both. The guest will ignore
* writes to the unused one.
*/
- kvm_ioapic_set_irq(kvm->arch.vioapic, irq, level);
- kvm_pic_set_irq(pic_irqchip(kvm), irq, level);
+ kvm_ioapic_set_irq(kvm->arch.vioapic, irq, !!(*irq_state));
+ kvm_pic_set_irq(pic_irqchip(kvm), irq, !!(*irq_state));
}
void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi)
@@ -132,3 +140,33 @@ void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
{
hlist_del(&kian->link);
}
+
+/* The caller must hold kvm->lock mutex */
+int kvm_request_irq_source_id(struct kvm *kvm)
+{
+ unsigned long *bitmap = (unsigned long *)&kvm->arch.irq_sources_bitmap;
+ int irq_source_id = find_first_zero_bit(bitmap,
+ sizeof(kvm->arch.irq_sources_bitmap));
+ if (irq_source_id >= sizeof(kvm->arch.irq_sources_bitmap)) {
+ printk(KERN_WARNING "kvm: exhaust allocatable IRQ sources!\n");
+ irq_source_id = -EFAULT;
+ } else
+ set_bit(irq_source_id, bitmap);
+ return irq_source_id;
+}
+
+void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id)
+{
+ int i;
+
+ if (irq_source_id <= 0 ||
+ irq_source_id >= sizeof(&kvm->arch.irq_sources_bitmap)) {
+ printk(KERN_ERR "kvm: IRQ source ID out of range!\n");
+ return;
+ }
+ for (i = 0; i < KVM_IOAPIC_NUM_PINS; i++)
+ clear_bit(irq_source_id,
+
[ kvm-Bugs-2138166 ] Vista guest fails to start on kvm-76
Bugs item #2138166, was opened at 2008-09-30 12:39 Message generated for change (Comment added) made by glommer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Vista guest fails to start on kvm-76 Initial Comment: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Build: kvm-76 Host kernel: 2.6.26.3-29.fc9.x86_64 Host arch: x86_64 Guest: Windows Vista Ultimate 64-bit QEMU command: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -std-vga -full-screen -smp 2 I've been running this guest on this host with kvm-75 without difficulty. kvm-76, built the same way that kvm-75 was (and on the same machine), fails to start my guest. The guest window is up, but the guest fails to complete startup. Command line output is: kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists set_vram_mapping failed kvm: get_dirty_pages returned -2 The last line repeats hundreds of times. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-10-02 16:27 Message: Are you using git? If so, can you bisect to find out who the culprit is? If not, I've managed to archive two strategic commits you should try: http://glommer.net/kvm-2646c5.tar.gz and http://glommer.net/kvm-d558461.tar.gz please report success or failure with them thanks! -- Comment By: John Rousseau (johnrrousseau) Date: 2008-10-02 15:48 Message: I applied the patch to kvm-76 and ran into basically the same problem. The guest still hung during boot and I got the plume of kvm: get_dirty_pages returned -2 errors, but the first message "kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists" wasn't displayed. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-10-02 13:01 Message: can you please test the patch at http://glommer.net/band-aid.patch ? -- Comment By: Brian Jackson (iggy_cav) Date: 2008-09-30 14:06 Message: This was reported on the mailing list. It's a problem with sdl output. Not specific to any guest. Until the problem is fixed, I'd suggest using vnc output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6 v3] PCI: add new general functions
On Saturday, September 27, 2008 1:27 am Zhao, Yu wrote:
> Centralize capability related functions into several new functions and put
> PCI resource definitions into an enum.
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index f99160d..f2feebc 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
The sysfs changes look fine, they should be submitted separately.
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 259eaff..400d3b3 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -356,25 +356,10 @@ pci_find_parent_resource(const struct pci_dev *dev,
> struct resource *res) static void
> pci_restore_bars(struct pci_dev *dev)
> {
> - int i, numres;
> -
> - switch (dev->hdr_type) {
> - case PCI_HEADER_TYPE_NORMAL:
> - numres = 6;
> - break;
> - case PCI_HEADER_TYPE_BRIDGE:
> - numres = 2;
> - break;
> - case PCI_HEADER_TYPE_CARDBUS:
> - numres = 1;
> - break;
> - default:
> - /* Should never get here, but just in case... */
> - return;
> - }
> + int i;
>
> - for (i = 0; i < numres; i ++)
> - pci_update_resource(dev, &dev->resource[i], i);
> + for (i = 0; i < PCI_BRIDGE_RESOURCES; i++)
> + pci_update_resource(dev, i);
> }
This confused me for a minute until I saw that the new pci_update_resource
ignores invalid BAR numbers. Not sure if that's clearer than the current
code...
> +/**
> + * pci_resource_bar - get position of the BAR associated with a resource
> + * @dev: the PCI device
> + * @resno: the resource number
> + * @type: the BAR type to be filled in
> + *
> + * Returns BAR position in config space, or 0 if the BAR is invalid.
> + */
> +int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type
> *type) +{
> + if (resno < PCI_ROM_RESOURCE) {
> + *type = pci_bar_unknown;
> + return PCI_BASE_ADDRESS_0 + 4 * resno;
> + } else if (resno == PCI_ROM_RESOURCE) {
> + *type = pci_bar_rom;
> + return dev->rom_base_reg;
> + }
> +
> + dev_err(&dev->dev, "BAR: invalid resource #%d\n", resno);
> + return 0;
> +}
It looks like this will spew an error even under normal circumstances since
pci_restore_bars gets called at resume time, right? You could make this into
a debug message or just get rid of it. Also now that I look at this, I don't
think it'll provide equivalent functionality to the old restore_bars code,
won't a cardbus bridge end up getting pci_update_resource called on invalid
BARs?
> +static void pci_init_capabilities(struct pci_dev *dev)
> +{
> + /* MSI/MSI-X list */
> + pci_msi_init_pci_dev(dev);
> +
> + /* Power Management */
> + pci_pm_init(dev);
> +
> + /* Vital Product Data */
> + pci_vpd_pci22_init(dev);
> +}
> +
These capabilities changes look good, care to separate them out?
Let's see if we can whittle down this patchset by extracting and applying all
the various cleanups; that should make the core bits easier to review.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6 v3] PCI: support ARI capability
On Thu, Oct 02, 2008 at 09:03:15AM -0700, Jesse Barnes wrote: > Maybe we should be consistent with the other APIs and call it pci_enable_ari > (like we do for wake & msi). Looks pretty good otherwise. Those APIs are for drivers ... this is internal. I don't have any objection of my own, though I agree with Alex's remark that the printk is unnecessary and just adds clutter to the boot process. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6 v3] PCI: support ARI capability
On Saturday, September 27, 2008 1:28 am Zhao, Yu wrote:
> Add Alternative Routing-ID Interpretation (ARI) support.
>
> Cc: Jesse Barnes <[EMAIL PROTECTED]>
> Cc: Randy Dunlap <[EMAIL PROTECTED]>
> Cc: Grant Grundler <[EMAIL PROTECTED]>
> Cc: Alex Chiang <[EMAIL PROTECTED]>
> Cc: Matthew Wilcox <[EMAIL PROTECTED]>
> Cc: Roland Dreier <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Signed-off-by: Yu Zhao <[EMAIL PROTECTED]>
>
> ---
> drivers/pci/pci.c| 31 +++
> drivers/pci/pci.h| 12
> drivers/pci/probe.c |3 +++
> include/linux/pci.h |1 +
> include/linux/pci_regs.h | 14 ++
> 5 files changed, 61 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 400d3b3..fe9efc4 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1260,6 +1260,37 @@ void pci_pm_init(struct pci_dev *dev)
> }
> }
>
> +/**
> + * pci_ari_init - turn on ARI forwarding if it's supported
> + * @dev: the PCI device
> + */
> +void pci_ari_init(struct pci_dev *dev)
> +{
> + int pos;
> + u32 cap;
> + u16 ctrl;
> +
> + if (!dev->is_pcie || (dev->pcie_type != PCI_EXP_TYPE_ROOT_PORT &&
> + dev->pcie_type != PCI_EXP_TYPE_DOWNSTREAM))
> + return;
> +
> + pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
> + if (!pos)
> + return;
> +
> + pci_read_config_dword(dev, pos + PCI_EXP_DEVCAP2, &cap);
> +
> + if (!(cap & PCI_EXP_DEVCAP2_ARI))
> + return;
> +
> + pci_read_config_word(dev, pos + PCI_EXP_DEVCTL2, &ctrl);
> + ctrl |= PCI_EXP_DEVCTL2_ARI;
> + pci_write_config_word(dev, pos + PCI_EXP_DEVCTL2, ctrl);
> +
> + dev->ari_enabled = 1;
> + dev_info(&dev->dev, "ARI forwarding enabled.\n");
> +}
> +
Maybe we should be consistent with the other APIs and call it pci_enable_ari
(like we do for wake & msi). Looks pretty good otherwise.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138166 ] Vista guest fails to start on kvm-76
Bugs item #2138166, was opened at 2008-09-30 08:39 Message generated for change (Comment added) made by johnrrousseau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Vista guest fails to start on kvm-76 Initial Comment: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Build: kvm-76 Host kernel: 2.6.26.3-29.fc9.x86_64 Host arch: x86_64 Guest: Windows Vista Ultimate 64-bit QEMU command: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -std-vga -full-screen -smp 2 I've been running this guest on this host with kvm-75 without difficulty. kvm-76, built the same way that kvm-75 was (and on the same machine), fails to start my guest. The guest window is up, but the guest fails to complete startup. Command line output is: kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists set_vram_mapping failed kvm: get_dirty_pages returned -2 The last line repeats hundreds of times. -- >Comment By: John Rousseau (johnrrousseau) Date: 2008-10-02 11:48 Message: I applied the patch to kvm-76 and ran into basically the same problem. The guest still hung during boot and I got the plume of kvm: get_dirty_pages returned -2 errors, but the first message "kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists" wasn't displayed. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-10-02 09:01 Message: can you please test the patch at http://glommer.net/band-aid.patch ? -- Comment By: Brian Jackson (iggy_cav) Date: 2008-09-30 10:06 Message: This was reported on the mailing list. It's a problem with sdl output. Not specific to any guest. Until the problem is fixed, I'd suggest using vnc output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] fix build breakage of qemu/kvm on ia64
Hi,
This one cleans up some problems with how the ia64 headers declared
'env' and also included stdio.h in cpu.h.
It builds and still boots kvm on my test system :-)
Cheers,
Jes
Fix build problem with latest kvm-userspace.git on ia64:
- Declare 'env' properly as on all other architectures, instead of
having a local decleration in every object.
- Introduce kvm_arch_try_push_nmi()
- Remove and cleanup fallout from having stdio.h included in cpu.h
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
---
qemu/qemu-kvm-ia64.c |5 +
qemu/target-ia64/cpu.h |6 +-
qemu/target-ia64/exec.h | 10 ++
qemu/target-ia64/fake-exec.c |2 ++
qemu/target-ia64/firmware.c |1 +
5 files changed, 19 insertions(+), 5 deletions(-)
Index: kvm-userspace.git/qemu/qemu-kvm-ia64.c
===
--- kvm-userspace.git.orig/qemu/qemu-kvm-ia64.c
+++ kvm-userspace.git/qemu/qemu-kvm-ia64.c
@@ -57,6 +57,11 @@
return 1;
}
+int kvm_arch_try_push_nmi(void *opaque)
+{
+return 1;
+}
+
void kvm_arch_update_regs_for_sipi(CPUState *env)
{
}
Index: kvm-userspace.git/qemu/target-ia64/cpu.h
===
--- kvm-userspace.git.orig/qemu/target-ia64/cpu.h
+++ kvm-userspace.git/qemu/target-ia64/cpu.h
@@ -26,7 +26,6 @@
#include "ia64intrin.h"
#include
-#include
#define TARGET_LONG_BITS 64
@@ -52,12 +51,9 @@
#define cpu_init cpu_ia64_init
#define cpu_signal_handler cpu_ia64_signal_handler
-struct CPUIA64State *env;
+extern struct CPUIA64State *env;
int cpu_get_pic_interrupt(CPUIA64State *s);
int cpu_exec(CPUState *env1);
-void cpu_dump_state(CPUState *env, FILE *f,
-int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
-int flags);
CPUState *cpu_ia64_init(const char * cpu_model);
static inline int cpu_mmu_index (CPUState *env)
Index: kvm-userspace.git/qemu/target-ia64/exec.h
===
--- kvm-userspace.git.orig/qemu/target-ia64/exec.h
+++ kvm-userspace.git/qemu/target-ia64/exec.h
@@ -18,13 +18,21 @@
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#ifndef __IA64_H__
+#define __IA64_H__
+
//#include "dyngen-exec.h"
+#include "config.h"
+
+#include "dyngen-exec.h"
#include "cpu.h"
#include "exec-all.h"
#define tcg_qemu_tb_exec(tb_ptr) 0
+register struct CPUIA64State *env asm(AREG0);
+
static inline void env_to_regs(void)
{
}
@@ -45,3 +53,5 @@
return 0;
return EXCP_HALTED;
}
+
+#endif
Index: kvm-userspace.git/qemu/target-ia64/fake-exec.c
===
--- kvm-userspace.git.orig/qemu/target-ia64/fake-exec.c
+++ kvm-userspace.git/qemu/target-ia64/fake-exec.c
@@ -14,6 +14,8 @@
* This work is licensed under the GNU GPL licence version 2 or later.
*
*/
+#include
+
#include "cpu.h"
#include "exec-all.h"
Index: kvm-userspace.git/qemu/target-ia64/firmware.c
===
--- kvm-userspace.git.orig/qemu/target-ia64/firmware.c
+++ kvm-userspace.git/qemu/target-ia64/firmware.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
Re: iommu external module
Muli Ben-Yehuda wrote: On Thu, Oct 02, 2008 at 03:45:33PM +0300, Avi Kivity wrote: We can fix this fairly simply by having an external module for the iommus, much like kvm itself. I don't think it should be too difficult, and it will provide a lot of testing to us, and important functionality for our users. The problem is that if we want to enable DMA translation for a given device, we have to do it before it has any outstanding DMAs. As long as you have a device that you want to enable translation for as built-in, you'll need the IOMMU built-in as well, or will need to reset the device when you load the IOMMU. That's why all IOMMUs are currently built-in. This is for using with kvm as an external module, so there is no question of a built in device. It's purely for older kernels; I'm not calling for modular iommus. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Patchset to enable vt-d support for kvm/ia64.
Zhang, Xiantao wrote:
+
+/* This should be called with the kvm->lock mutex held */
+void kvm_set_irq(struct kvm *kvm, int irq, int level)
+{
+ /* Not possible to detect if the guest uses the PIC or the
+* IOAPIC. So set the bit in both. The guest will ignore
+* writes to the unused one.
+*/
+ kvm_ioapic_set_irq(kvm->arch.vioapic, irq, level);
+#ifdef X86
+ kvm_pic_set_irq(pic_irqchip(kvm), irq, level);
+#endif
+}
Will non-x86, non-ia64 archs survive this?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unalias rework
Marcelo Tosatti wrote:
Hi Izik,
On Thu, Sep 04, 2008 at 05:13:20PM +0300, izik eidus wrote:
+struct kvm_memory_slot *alias_slot = &kvm->memslots[i];
+
+if (alias_slot->base_gfn == slot->base_gfn)
+return 1;
+}
+return 0;
+}
+
+static void update_alias_slots(struct kvm *kvm, struct
kvm_memory_slot *free)
+{
+int i;
+
+if (is_aliased_slot(kvm, free))
+return;
+
+for (i = KVM_MEMORY_SLOTS; i < KVM_MEMORY_SLOTS + KVM_ALIAS_SLOTS;
+ ++i) {
+struct kvm_memory_slot *alias_memslot = &kvm->memslots[i];
+unsigned long size = free->npages << PAGE_SHIFT;
+
+if (alias_memslot->userspace_addr >= free->userspace_addr &&
+alias_memslot->userspace_addr < free->userspace_addr +
+size) {
+alias_memslot->flags = free->flags;
+if (free->dirty_bitmap) {
+unsigned long offset =
+alias_memslot->userspace_addr -
+free->userspace_addr;
+unsigned dirty_offset;
+unsigned long bitmap_addr;
+
+offset = offset >> PAGE_SHIFT;
+dirty_offset = ALIGN(offset, BITS_PER_LONG) / 8;
+bitmap_addr = (unsigned long) free->dirty_bitmap;
+bitmap_addr += dirty_offset;
+alias_memslot->dirty_bitmap = (unsigned long *)
bitmap_addr;
+} else
+alias_memslot->dirty_bitmap = NULL;
+}
+}
+}
+
/*
* Free any memory in @free but not in @dont.
*/
-static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
+static void kvm_free_physmem_slot(struct kvm *kvm,
+ struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
if (!dont || free->rmap != dont->rmap)
@@ -385,10 +433,16 @@ static void kvm_free_physmem_slot(struct
kvm_memory_slot *free,
if (!dont || free->lpage_info != dont->lpage_info)
vfree(free->lpage_info);
-free->npages = 0;
free->dirty_bitmap = NULL;
free->rmap = NULL;
free->lpage_info = NULL;
+
+#ifdef CONFIG_X86
+update_alias_slots(kvm, free);
+if (dont)
+update_alias_slots(kvm, dont);
+#endif
+free->npages = 0;
Why is this needed? I don't understand when would you free a memslot
without freeing any aliases that map it first?
(sent it already, but for some reason it didnt reach to the mailing list)
beacuse in case of dont != NULL, we actually dont free the memslot...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] Patchset to enable vt-d support for kvm/ia64.
Hi, Avi
Sorry, seems irq_comm.c is missing when I generate the patchset.
Attach it! Could you help to apply the patchset ? :-)
Xiantao
>From cc77672cdfb5a566d1c7e86d91c07d6db99ad8c0 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Sat, 27 Sep 2008 11:29:14 +0800
Subject: [PATCH] kvm: Split arch/x86/kvm/irq.c to two parts.
Moving irq ack notification logic as common, and make
it shared with ia64 side.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/include/asm/kvm_host.h |4 ++
arch/ia64/kvm/Makefile |2 +-
arch/ia64/kvm/irq.h |5 ---
arch/x86/kvm/Makefile|2 +-
arch/x86/kvm/irq.c | 33 -
arch/x86/kvm/irq.h |8 -
include/asm-x86/kvm_host.h |2 +
include/linux/kvm_host.h |6
virt/kvm/irq_comm.c | 59
++
9 files changed, 73 insertions(+), 48 deletions(-)
create mode 100644 virt/kvm/irq_comm.c
diff --git a/arch/ia64/include/asm/kvm_host.h
b/arch/ia64/include/asm/kvm_host.h
index 1efe513..da579a3 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -413,6 +413,10 @@ struct kvm_arch {
struct kvm_ioapic *vioapic;
struct kvm_vm_stat stat;
struct kvm_sal_data rdv_sal_data;
+
+ struct list_head assigned_dev_head;
+ struct dmar_domain *intel_iommu_domain;
+ struct hlist_head irq_ack_notifier_list;
};
union cpuid3_t {
diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index bf22fb9..c96f19f 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -44,7 +44,7 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
EXTRA_AFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \
- coalesced_mmio.o)
+ coalesced_mmio.o irq_comm.o)
kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/arch/ia64/kvm/irq.h b/arch/ia64/kvm/irq.h
index f2e6545..604329a 100644
--- a/arch/ia64/kvm/irq.h
+++ b/arch/ia64/kvm/irq.h
@@ -23,10 +23,5 @@
#ifndef __IRQ_H
#define __IRQ_H
-struct kvm;
-
-static inline void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi)
-{
-}
#endif
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index 7dce593..0d2cf3f 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -3,7 +3,7 @@
#
common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \
-coalesced_mmio.o)
+coalesced_mmio.o irq_comm.o)
ifeq ($(CONFIG_KVM_TRACE),y)
common-objs += $(addprefix ../../../virt/kvm/, kvm_trace.o)
endif
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 8c1b9c5..c019b8e 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -99,36 +99,3 @@ void __kvm_migrate_timers(struct kvm_vcpu *vcpu)
__kvm_migrate_apic_timer(vcpu);
__kvm_migrate_pit_timer(vcpu);
}
-
-/* This should be called with the kvm->lock mutex held */
-void kvm_set_irq(struct kvm *kvm, int irq, int level)
-{
- /* Not possible to detect if the guest uses the PIC or the
-* IOAPIC. So set the bit in both. The guest will ignore
-* writes to the unused one.
-*/
- kvm_ioapic_set_irq(kvm->arch.vioapic, irq, level);
- kvm_pic_set_irq(pic_irqchip(kvm), irq, level);
-}
-
-void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi)
-{
- struct kvm_irq_ack_notifier *kian;
- struct hlist_node *n;
-
- hlist_for_each_entry(kian, n, &kvm->arch.irq_ack_notifier_list,
link)
- if (kian->gsi == gsi)
- kian->irq_acked(kian);
-}
-
-void kvm_register_irq_ack_notifier(struct kvm *kvm,
- struct kvm_irq_ack_notifier *kian)
-{
- hlist_add_head(&kian->link, &kvm->arch.irq_ack_notifier_list);
-}
-
-void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
-struct kvm_irq_ack_notifier *kian)
-{
- hlist_del(&kian->link);
-}
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 4748532..f17c8f5 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -68,7 +68,6 @@ struct kvm_pic {
};
struct kvm_pic *kvm_create_pic(struct kvm *kvm);
-void kvm_pic_set_irq(void *opaque, int irq, int level);
int kvm_pic_read_irq(struct kvm *kvm);
void kvm_pic_update_irq(struct kvm_pic *s);
void kvm_pic_clear_isr_ack(struct kvm *kvm);
@@ -85,13 +84,6 @@ static inline int irqchip_in_kernel(struct kvm *kvm)
void kvm_pic_reset(struct kvm_kpic_state *s);
-void kvm_set_irq(struct kvm *kvm, int irq, int level);
-void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi);
-void kvm_register_irq_ack_notifier(struct kvm *kvm,
- struct kvm_irq_ack_notifier *kian);
-void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
-struct kvm_irq_ack_not
Re: [PATCH] fix compilation with --disable-kvm
On Thu, Oct 2, 2008 at 11:31 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Glauber Costa wrote:
>>
>> Currently, kvm is failing to build with --disable-kvm.
>> this patch fixes the issue.
>>
>>
>
> Replaced, thanks.
>
>> #define qemu_kvm_irqchip_in_kernel() (0)
>> #define qemu_kvm_pit_in_kernel() (0)
>> #define qemu_kvm_has_sync_mmu() (0)
>> +#define kvm_load_registers(env) do {} while(0)
>> +#define kvm_save_registers(env) do {} while(0)
>> #endif
>>
>
> The alias functions want to be here too?
maybe, but it should not require a kvm context anyway, when called
from qemu code.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iommu external module
On Thu, Oct 02, 2008 at 03:45:33PM +0300, Avi Kivity wrote: > We can fix this fairly simply by having an external module for the > iommus, much like kvm itself. I don't think it should be too > difficult, and it will provide a lot of testing to us, and important > functionality for our users. The problem is that if we want to enable DMA translation for a given device, we have to do it before it has any outstanding DMAs. As long as you have a device that you want to enable translation for as built-in, you'll need the IOMMU built-in as well, or will need to reset the device when you load the IOMMU. That's why all IOMMUs are currently built-in. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ <-> SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix compilation with --disable-kvm
Currently, kvm is failing to build with --disable-kvm.
this patch fixes the issue.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c |6 +-
qemu/hw/cirrus_vga.c |7 +++
qemu/qemu-kvm.h |2 ++
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 05f5dc0..7a7a534 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -726,7 +726,11 @@ void qemu_system_cpu_hot_add(int cpu, int state)
{
CPUState *env;
-if ((state) && (!qemu_kvm_cpu_env(cpu))) {
+if (state
+#ifdef USE_KVM
+&& (!qemu_kvm_cpu_env(cpu))
+#endif
+) {
env = pc_new_cpu(cpu, model, 1);
if (!env) {
fprintf(stderr, "cpu %d creation failed\n", cpu);
diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index 4f3aef9..dac0731 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -2677,14 +2677,13 @@ static void kvm_update_vga_alias(CirrusVGAState *s, int
ok, int bank)
if (!s->aliases_enabled
|| base != s->aliased_bank_base[bank]
|| limit != s->aliased_bank_limit[bank]) {
- kvm_create_memory_alias(kvm_context,
- 0xa + bank * 0x8000,
- limit, base);
+ kvm_qemu_create_memory_alias(0xa + bank * 0x8000,
+ limit, base);
s->aliased_bank_base[bank] = base;
s->aliased_bank_limit[bank] = limit;
}
} else {
- kvm_destroy_memory_alias(kvm_context, 0xa + bank * 0x8000);
+ kvm_qemu_destroy_memory_alias(0xa + bank * 0x8000);
}
}
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index fd9d5d1..330b2dc 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -107,6 +107,8 @@ extern kvm_context_t kvm_context;
#define qemu_kvm_irqchip_in_kernel() (0)
#define qemu_kvm_pit_in_kernel() (0)
#define qemu_kvm_has_sync_mmu() (0)
+#define kvm_load_registers(env) do {} while(0)
+#define kvm_save_registers(env) do {} while(0)
#endif
void kvm_mutex_unlock(void);
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix compilation with --disable-kvm
Glauber Costa wrote:
Currently, kvm is failing to build with --disable-kvm.
this patch fixes the issue.
Replaced, thanks.
#define qemu_kvm_irqchip_in_kernel() (0)
#define qemu_kvm_pit_in_kernel() (0)
#define qemu_kvm_has_sync_mmu() (0)
+#define kvm_load_registers(env) do {} while(0)
+#define kvm_save_registers(env) do {} while(0)
#endif
The alias functions want to be here too?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2135061 ] vde support disabled
Bugs item #2135061, was opened at 2008-09-29 04:51 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2135061&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Shen Okinudo (okinu) Assigned to: Nobody/Anonymous (nobody) Summary: vde support disabled Initial Comment: Even when not using the "--disable-vde" configuratiion flag vde-support shows up with "no". Thias happens on an Intel 64 bit host. -- Comment By: Anthony Liguori (aliguori) Date: 2008-09-29 17:42 Message: Do you have the vde development libraries installed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2135061&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: ok i don't know any other solution so - install kvm-71 to the host - install a guest mandrake-10 truly minimal install into file image - upgrade to kvm-76 and the guest no longer boot. so i've uploaded it for you into: ftp://ftp.bppiac.hu/mandrake.img.bz2 (this is the bzip-ed image:-) can you try to boot this image with kvm-76 (or anything later than kvm-71)? Just ran this on my desktop, it booted fine... -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unalias rework
Marcelo Tosatti wrote:
Hi Izik,
On Thu, Sep 04, 2008 at 05:13:20PM +0300, izik eidus wrote:
+ struct kvm_memory_slot *alias_slot = &kvm->memslots[i];
+
+ if (alias_slot->base_gfn == slot->base_gfn)
+ return 1;
+ }
+ return 0;
+}
+
+static void update_alias_slots(struct kvm *kvm, struct kvm_memory_slot *free)
+{
+ int i;
+
+ if (is_aliased_slot(kvm, free))
+ return;
+
+ for (i = KVM_MEMORY_SLOTS; i < KVM_MEMORY_SLOTS + KVM_ALIAS_SLOTS;
+++i) {
+ struct kvm_memory_slot *alias_memslot = &kvm->memslots[i];
+ unsigned long size = free->npages << PAGE_SHIFT;
+
+ if (alias_memslot->userspace_addr >= free->userspace_addr &&
+ alias_memslot->userspace_addr < free->userspace_addr +
+ size) {
+ alias_memslot->flags = free->flags;
+ if (free->dirty_bitmap) {
+ unsigned long offset =
+ alias_memslot->userspace_addr -
+ free->userspace_addr;
+ unsigned dirty_offset;
+ unsigned long bitmap_addr;
+
+ offset = offset >> PAGE_SHIFT;
+ dirty_offset = ALIGN(offset, BITS_PER_LONG) / 8;
+ bitmap_addr = (unsigned long)
free->dirty_bitmap;
+ bitmap_addr += dirty_offset;
+ alias_memslot->dirty_bitmap = (unsigned long *)
bitmap_addr;
+ } else
+ alias_memslot->dirty_bitmap = NULL;
+ }
+ }
+}
+
/*
* Free any memory in @free but not in @dont.
*/
-static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
+static void kvm_free_physmem_slot(struct kvm *kvm,
+ struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
if (!dont || free->rmap != dont->rmap)
@@ -385,10 +433,16 @@ static void kvm_free_physmem_slot(struct kvm_memory_slot
*free,
if (!dont || free->lpage_info != dont->lpage_info)
vfree(free->lpage_info);
- free->npages = 0;
free->dirty_bitmap = NULL;
free->rmap = NULL;
free->lpage_info = NULL;
+
+#ifdef CONFIG_X86
+ update_alias_slots(kvm, free);
+ if (dont)
+ update_alias_slots(kvm, dont);
+#endif
+ free->npages = 0;
Why is this needed? I don't understand when would you free a memslot
without freeing any aliases that map it first?
(sent it already, but for some reason it didnt reach to the mailing list)
beacuse in case of dont != NULL, we actually dont free the memslot...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Avi Kivity wrote: > Farkas Levente wrote: >> still not working with kvm-76 userspace but still working with kvm-71 >> userspace and kmod-76. what else can i do? >> > > What's the guest kernel? Is it updated relative to the madrake-10 release? > > I was able to install and run mandrake 10 a couple of weeks ago, so > maybe this only happens together with an update. ok i don't know any other solution so - install kvm-71 to the host - install a guest mandrake-10 truly minimal install into file image - upgrade to kvm-76 and the guest no longer boot. so i've uploaded it for you into: ftp://ftp.bppiac.hu/mandrake.img.bz2 (this is the bzip-ed image:-) can you try to boot this image with kvm-76 (or anything later than kvm-71)? -- Levente "Si vis pacem para bellum!" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] Fix guest shared interrupt with in-kernel irqchip
On Thu, Oct 02, 2008 at 04:27:18PM +0300, Avi Kivity wrote: > Yang, Sheng wrote: >> To deal with guest shared interrupt bug in in-kernel irqchip, we should: >> >> 1. Identify each level trig interrupt source. >> 2. Implement logical OR on the same IRQ line for each interrupt source. >> >> Here I chose a simple method: the caller of kvm_set_irq() has responsiblity >> to identify interrupt sources, and IOAPIC/PIC ensure logical OR on IRQ line. >> > > The downside is that every caller has to do this edge detection. > > How about allocating a vector of u32s (one per irq), and each source > will allocate a bit within this vector. The 'or' operation becomes > (word != 0). Oh, that's what I called the "alternative" one... I just think the request/allocation/free make thing complicate and unnecessary for now, for we are already ensure that kvm_set_irq() are called in pair. I once think if we use resource allocating method, the irqs should bind with the resources, and it's unnecessary. But I think your method is better, reserve one bit for each source on every irq_state make things simpler. OK, I will update the patch following this method. -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2063072 ] compiling problem with "tcg_ctx"
Bugs item #2063072, was opened at 2008-08-21 00:29
Message generated for change (Comment added) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2063072&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jana Delego (janado)
Assigned to: Anthony Liguori (aliguori)
Summary: compiling problem with "tcg_ctx"
Initial Comment:
When compiling kvm using the "--disable-cpu-emulation" flag on a 64 bit Intel
Ubuntu, the compiler aborts with error "undefined reference to tcg_ctx",
This problem exists since kvm-70.
--
>Comment By: Avi Kivity (avik)
Date: 2008-10-02 17:05
Message:
Well, it would be nice to support --disable-cpu-emulation, for example if
you're worried about tcg security holes or tcg performance.
--
Comment By: Anthony Liguori (aliguori)
Date: 2008-09-29 16:56
Message:
--disable-cpu-emulation should not be used with x86. It only exists as an
ugly hack because ia64 doesn't support TCG.
--
Comment By: Shen Okinudo (okinu)
Date: 2008-09-29 04:37
Message:
This bug persists in kvm-76
--
Comment By: Marshal Newrock (freedombi)
Date: 2008-09-02 02:40
Message:
Logged In: YES
user_id=2201280
Originator: NO
This seems to work with kvm-74. The patch allowed compilation, and the
guest appears to be running well.
--
Comment By: Amit Shah (amitshah)
Date: 2008-08-29 12:59
Message:
Logged In: YES
user_id=201894
Originator: NO
I'm not sure if this will make qemu work properly, but it fixes the build
(also attached). Can you confirm if this works?
commit 244cafe6688940c25c81b31aa223c9e24656806e
Author: Amit Shah <[EMAIL PROTECTED]>
Date: Fri Aug 29 15:20:14 2008 +0530
KVM: QEMU: Fix userspace build with --disable-cpu-emulation
I'm not sure this will work properly, but fixes the build.
ppc might need something like this as well
Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
diff --git a/qemu/target-i386/fake-exec.c b/qemu/target-i386/fake-exec.c
index 737286d..552089b 100644
--- a/qemu/target-i386/fake-exec.c
+++ b/qemu/target-i386/fake-exec.c
@@ -12,6 +12,13 @@
*/
#include "exec.h"
#include "cpu.h"
+#include "tcg.h"
+
+/* code generation context */
+TCGContext tcg_ctx;
+
+uint16_t gen_opc_buf[OPC_BUF_SIZE];
+TCGArg gen_opparam_buf[OPPARAM_BUF_SIZE];
int code_copy_enabled = 0;
@@ -45,10 +52,6 @@ int cpu_x86_gen_code(CPUState *env, TranslationBlock
*tb, int *gen_code_size_ptr
return 0;
}
-void flush_icache_range(unsigned long start, unsigned long stop)
-{
-}
-
void optimize_flags_init(void)
{
}
File Added: 0001-KVM-QEMU-Fix-userspace-build-with-disable-cpu-em.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2063072&group_id=180599
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138079 ] kvm locks up system
Bugs item #2138079, was opened at 2008-09-30 14:36 Message generated for change (Comment added) made by edwin128 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138079&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torok Edwin (edwin128) Assigned to: Nobody/Anonymous (nobody) Summary: kvm locks up system Initial Comment: Sometimes KVM locks up the entire system for several minutes. When this happens I can't use neither the keyboard nor the mouse. I can login remotely using ssh and kill kvm, and then keyboard is restored after a short while, however I need to restart X, because the mouse remains grabbed. Last time it happened while using a NetBSD 4.0 (x86_64) image. I've done a commit all on the qemu console, then switched back to the guest, and I couldn't type anything, after that I couldn't exit the grab either, and after that the system locked up. I had gkrellm running, and it showed 1 core having 100% system time, while the other 3 cores were idle. Before this happened were at 99% user CPU usage, from another process (not kvm/qemu). System info: * distro: Debian unstable * CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz * KVM version: 76 * host kernel: 2.6.26-1-amd64 #1 SMP Wed Sep 24 13:59:41 UTC 2008 x86_64 GNU/Linux * host arch: x86_64 * guest: x86_64, NetBSD 4.0 (on serial console, boot fails if using text console) * qemu cmdline: sudo qemu-system-x86_64 -hda netbsd4.img -snapshot -m 1024 -cdrom /tmp/x.iso * the problem only appears with kvm, I never encountered this when using -no-kvm, or when using qemu w/ kqemu. * this problem also occured when running a Solaris 10 guest OS dmesg output during lockup below. See also kerneloops entry: http://kerneloops.org/guilty.php?guilty=apic_mmio_read&version=2.6.26-release&start=1736704&end=1769471&class=oops [12518.803078] loaded kvm module (kvm-76) [12564.289154] kvm: emulating exchange as write [13926.593155] kvm: inject_page_fault: double fault 0x80c0bfa8 [14015.554904] BUG: soft lockup - CPU#1 stuck for 61s! [qemu-system-x86:20613] [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] CPU 1: [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] Pid: 20613, comm: qemu-system-x86 Tainted: P 2.6.26-1-amd64 #1 [14015.554904] RIP: 0010:[] [] :kvm:apic_mmio_read+0xf0/0x17d [14015.554904] RSP: 0018:81000821dc88 EFLAGS: 0202 [14015.554904] RAX: 62126c0cf17912e9 RBX: 0390 RCX: 62126c0cf2841a1b [14015.554904] RDX: 010b0732 RSI: 010b0732 RDI: fef4f8ce [14015.554904] RBP: fee0017b R08: 0001 R09: 0c12 [14015.554904] R10: R11: a0c60c5b R12: 000380281e01 [14015.554904] R13: 00c18dc0 R14: 0003 R15: 809b8390 [14015.554904] FS: 420ce950() GS:81012fa7c8c0() knlGS: [14015.554904] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [14015.554904] CR2: CR3: 91b53000 CR4: 26e0 [14015.554904] DR0: 000
[ kvm-Bugs-2138079 ] kvm locks up system
Bugs item #2138079, was opened at 2008-09-30 14:36 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138079&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torok Edwin (edwin128) Assigned to: Nobody/Anonymous (nobody) Summary: kvm locks up system Initial Comment: Sometimes KVM locks up the entire system for several minutes. When this happens I can't use neither the keyboard nor the mouse. I can login remotely using ssh and kill kvm, and then keyboard is restored after a short while, however I need to restart X, because the mouse remains grabbed. Last time it happened while using a NetBSD 4.0 (x86_64) image. I've done a commit all on the qemu console, then switched back to the guest, and I couldn't type anything, after that I couldn't exit the grab either, and after that the system locked up. I had gkrellm running, and it showed 1 core having 100% system time, while the other 3 cores were idle. Before this happened were at 99% user CPU usage, from another process (not kvm/qemu). System info: * distro: Debian unstable * CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz * KVM version: 76 * host kernel: 2.6.26-1-amd64 #1 SMP Wed Sep 24 13:59:41 UTC 2008 x86_64 GNU/Linux * host arch: x86_64 * guest: x86_64, NetBSD 4.0 (on serial console, boot fails if using text console) * qemu cmdline: sudo qemu-system-x86_64 -hda netbsd4.img -snapshot -m 1024 -cdrom /tmp/x.iso * the problem only appears with kvm, I never encountered this when using -no-kvm, or when using qemu w/ kqemu. * this problem also occured when running a Solaris 10 guest OS dmesg output during lockup below. See also kerneloops entry: http://kerneloops.org/guilty.php?guilty=apic_mmio_read&version=2.6.26-release&start=1736704&end=1769471&class=oops [12518.803078] loaded kvm module (kvm-76) [12564.289154] kvm: emulating exchange as write [13926.593155] kvm: inject_page_fault: double fault 0x80c0bfa8 [14015.554904] BUG: soft lockup - CPU#1 stuck for 61s! [qemu-system-x86:20613] [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] CPU 1: [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] Pid: 20613, comm: qemu-system-x86 Tainted: P 2.6.26-1-amd64 #1 [14015.554904] RIP: 0010:[] [] :kvm:apic_mmio_read+0xf0/0x17d [14015.554904] RSP: 0018:81000821dc88 EFLAGS: 0202 [14015.554904] RAX: 62126c0cf17912e9 RBX: 0390 RCX: 62126c0cf2841a1b [14015.554904] RDX: 010b0732 RSI: 010b0732 RDI: fef4f8ce [14015.554904] RBP: fee0017b R08: 0001 R09: 0c12 [14015.554904] R10: R11: a0c60c5b R12: 000380281e01 [14015.554904] R13: 00c18dc0 R14: 0003 R15: 809b8390 [14015.554904] FS: 420ce950() GS:81012fa7c8c0() knlGS: [14015.554904] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [14015.554904] CR2: CR3: 91b53000 CR4: 26e0 [14015.554904] DR0: 000
Re: [PATCH 2/2] fix compilation with --disable-kvm
Glauber Costa wrote: On Thu, Oct 02, 2008 at 04:43:06PM +0300, Avi Kivity wrote: Glauber Costa wrote: -kvm_save_registers(mon_cpu); +if (kvm_enabled()) +kvm_save_registers(mon_cpu); If I'm not mistaken, this relies on the optimizer to remove the call to kvm_save_registers(). Compilation with -O0 will break. I think a better solution is to have kvm_save_registers() contain the kvm_enabled() check, and also be defined to an empty function if kvm is disabled at compile time. ok master. Will redo. I applied it already (since it fixes an issue), so base it on kvm-userspace.git (once I push). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fix compilation with --disable-kvm
On Thu, Oct 02, 2008 at 04:43:06PM +0300, Avi Kivity wrote: > Glauber Costa wrote: >> -kvm_save_registers(mon_cpu); >> +if (kvm_enabled()) >> +kvm_save_registers(mon_cpu); >> > > If I'm not mistaken, this relies on the optimizer to remove the call to > kvm_save_registers(). Compilation with -O0 will break. > > I think a better solution is to have kvm_save_registers() contain the > kvm_enabled() check, and also be defined to an empty function if kvm is > disabled at compile time. ok master. Will redo. > > -- > error compiling committee.c: too many arguments to function > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138079 ] kvm locks up system
Bugs item #2138079, was opened at 2008-09-30 11:36 Message generated for change (Comment added) made by glommer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138079&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torok Edwin (edwin128) Assigned to: Nobody/Anonymous (nobody) Summary: kvm locks up system Initial Comment: Sometimes KVM locks up the entire system for several minutes. When this happens I can't use neither the keyboard nor the mouse. I can login remotely using ssh and kill kvm, and then keyboard is restored after a short while, however I need to restart X, because the mouse remains grabbed. Last time it happened while using a NetBSD 4.0 (x86_64) image. I've done a commit all on the qemu console, then switched back to the guest, and I couldn't type anything, after that I couldn't exit the grab either, and after that the system locked up. I had gkrellm running, and it showed 1 core having 100% system time, while the other 3 cores were idle. Before this happened were at 99% user CPU usage, from another process (not kvm/qemu). System info: * distro: Debian unstable * CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz * KVM version: 76 * host kernel: 2.6.26-1-amd64 #1 SMP Wed Sep 24 13:59:41 UTC 2008 x86_64 GNU/Linux * host arch: x86_64 * guest: x86_64, NetBSD 4.0 (on serial console, boot fails if using text console) * qemu cmdline: sudo qemu-system-x86_64 -hda netbsd4.img -snapshot -m 1024 -cdrom /tmp/x.iso * the problem only appears with kvm, I never encountered this when using -no-kvm, or when using qemu w/ kqemu. * this problem also occured when running a Solaris 10 guest OS dmesg output during lockup below. See also kerneloops entry: http://kerneloops.org/guilty.php?guilty=apic_mmio_read&version=2.6.26-release&start=1736704&end=1769471&class=oops [12518.803078] loaded kvm module (kvm-76) [12564.289154] kvm: emulating exchange as write [13926.593155] kvm: inject_page_fault: double fault 0x80c0bfa8 [14015.554904] BUG: soft lockup - CPU#1 stuck for 61s! [qemu-system-x86:20613] [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] CPU 1: [14015.554904] Modules linked in: kvm_intel kvm tun kqemu ppdev parport_pc lp parport nvidia(P) ipv6 video output ac battery xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand xfs reiserfs acpi_cpufreq freq_table coretemp it87 hwmon_vid sbp2 loop ide_cd_mod cdrom ide_pci_generic jmicron snd_pcm_oss snd_mixer_oss ide_core snd_hda_intel ohci1394 i2c_i801 serio_raw snd_seq_dummy i2c_core snd_seq_oss floppy ieee1394 ata_generic pcspkr snd_pcm psmouse snd_seq_midi_event r8169 sata_sil24 snd_seq snd_timer snd_seq_device ehci_hcd button uhci_hcd snd soundcore snd_page_alloc intel_agp evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid1 md_mod sd_mod thermal processor fan thermal_sys ahci libata scsi_mod dock [last unloaded: kvm] [14015.554904] Pid: 20613, comm: qemu-system-x86 Tainted: P 2.6.26-1-amd64 #1 [14015.554904] RIP: 0010:[] [] :kvm:apic_mmio_read+0xf0/0x17d [14015.554904] RSP: 0018:81000821dc88 EFLAGS: 0202 [14015.554904] RAX: 62126c0cf17912e9 RBX: 0390 RCX: 62126c0cf2841a1b [14015.554904] RDX: 010b0732 RSI: 010b0732 RDI: fef4f8ce [14015.554904] RBP: fee0017b R08: 0001 R09: 0c12 [14015.554904] R10: R11: a0c60c5b R12: 000380281e01 [14015.554904] R13: 00c18dc0 R14: 0003 R15: 809b8390 [14015.554904] FS: 420ce950() GS:81012fa7c8c0() knlGS: [14015.554904] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [14015.554904] CR2: CR3: 91b53000 CR4: 26e0 [14015.554904] DR0:
Re: [PATCH 2/2] fix compilation with --disable-kvm
Glauber Costa wrote: -kvm_save_registers(mon_cpu); +if (kvm_enabled()) +kvm_save_registers(mon_cpu); If I'm not mistaken, this relies on the optimizer to remove the call to kvm_save_registers(). Compilation with -O0 will break. I think a better solution is to have kvm_save_registers() contain the kvm_enabled() check, and also be defined to an empty function if kvm is disabled at compile time. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] KVM failing to compile with --disable-kvm
Glauber Costa wrote: Father Avi, is it better now? Yes, applied. thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] Fix guest shared interrupt with in-kernel irqchip
Yang, Sheng wrote:
To deal with guest shared interrupt bug in in-kernel irqchip, we should:
1. Identify each level trig interrupt source.
2. Implement logical OR on the same IRQ line for each interrupt source.
Here I chose a simple method: the caller of kvm_set_irq() has responsiblity
to identify interrupt sources, and IOAPIC/PIC ensure logical OR on IRQ line.
The downside is that every caller has to do this edge detection.
How about allocating a vector of u32s (one per irq), and each source
will allocate a bit within this vector. The 'or' operation becomes
(word != 0).
For example:
irq_src = kvm_irq_allocate_source(kvm); /* allocate bit within irq
vector */
...
kvm_set_irq(kvm, irq, 1, irq_src);
kvm_set_irq(...)
{
// locking?
if (level)
set_bit(irq_src, &kvm->irq_state[irq]);
else
clear_bit(irq_src, &kvm->irq_state[irq]);
kvm_pic_set_irq(kvm, irq, !!kvm->irq_state[irq]);
kvm_ioapic_set_irq(kvm, irq, !!kvm->irq_state[irq]);
}
kvm_irq_allocate_source(kvm)
{
irq_src = find_first_clear_bit(kvm->irq_sources);
set_bit(irq_src, &kvm->irq_sources);
return irq_src;
}
This also keeps the pic and ioapic out of the picture, which is good.
It also allows us to implement negative polarity easily in the future.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Patchset to enable vt-d support for kvm/ia64.
Zhang, Xiantao wrote: In order to enable vt-d suport for kvm/ia64 guests, I worked out the patchset to make it happen. Please review. The first five patches have no changes for logic and just do code move. Xiantao [PATCH 1/8] kvm/vt-d: Moving vtd.c from arch/x86/kvm/ to virt/kvm/ [PATCH 2/8] kvm: Moving device_assignment logic to kvm_main.c [PATCH 3/8] kvm: Changing is_mmio_pfn to kvm_is_mmio_pfn, and make it common [PATCH 4/8] kvm: Split arch/x86/kvm/irq.c to two parts. [PATCH 5/8] kvm: Moving irqchip_in_kernel from ioapic.h to irq.h [PATCH 6/8] kvm/ia64: Make pmt table be able to hold physical mmio entries. [PATCH 7/8] kvm/ia64: Add directed mmio range support for kvm guests. [PATCH 8/8] kvm/ia64: Add intel iommu support for guests Apart from my comment on patch 4, this series looks good. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] kvm-userspace: kvmppc: fix build for ppc v2
[EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> *update Short after resending v1 I realized that I forgot to put Avi and [EMAIL PROTECTED] (for 2/3) on cc. I also updated the header text in 1/3 a bit and verified my hostlongbits proposal on recent cross toolchain versions because there was a question about that. Updating and testing kvm-userspace for ppc after a too long time brought up some issues fixed in this series. The patches are small and their description should be comprehendible. Due to the fact that most of the issues where build time issues I also started to discuss about/establish some kind of automated build test for us that should allow us to find such things faster. Let me know if qumranet has such a process for x86 already and I should help you to include powerpc. [patches in series] [PATCH 1/3] kvm-userspace: kvmppc: fix file header in libkvm-powerpc.c [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling [PATCH 3/3] kvm-userspace: kvmppc: fix building userspace for powerpc Applied 1 and 3, thanks. 2 appears to have already been merged via qemu upstream. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8]kvm: Split arch/x86/kvm/irq.c to two parts.
Zhang, Xiantao wrote:
From bb0c01b997d16ff1c1b9b0e797a581577c385b54 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Mon, 29 Sep 2008 10:59:30 +0800
Subject: [PATCH] kvm: Split arch/x86/kvm/irq.c to two parts.
Moving irq ack notification logic as common, and make
it shared with ia64 side.
8 files changed, 14 insertions(+), 48 deletions(-)
Warning sign - more deletions than insertions.
__kvm_migrate_pit_timer(vcpu);
}
-
-/* This should be called with the kvm->lock mutex held */
-void kvm_set_irq(struct kvm *kvm, int irq, int level)
-{
- /* Not possible to detect if the guest uses the PIC or the
-* IOAPIC. So set the bit in both. The guest will ignore
-* writes to the unused one.
-*/
- kvm_ioapic_set_irq(kvm->arch.vioapic, irq, level);
- kvm_pic_set_irq(pic_irqchip(kvm), irq, level);
-}
-
-void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi)
-{
- struct kvm_irq_ack_notifier *kian;
- struct hlist_node *n;
-
- hlist_for_each_entry(kian, n, &kvm->arch.irq_ack_notifier_list,
link)
- if (kian->gsi == gsi)
- kian->irq_acked(kian);
-}
-
-void kvm_register_irq_ack_notifier(struct kvm *kvm,
- struct kvm_irq_ack_notifier *kian)
-{
- hlist_add_head(&kian->link, &kvm->arch.irq_ack_notifier_list);
-}
-
-void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
-struct kvm_irq_ack_notifier *kian)
-{
- hlist_del(&kian->link);
-}
Where did these go?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2138166 ] Vista guest fails to start on kvm-76
Bugs item #2138166, was opened at 2008-09-30 12:39 Message generated for change (Comment added) made by glommer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Vista guest fails to start on kvm-76 Initial Comment: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Build: kvm-76 Host kernel: 2.6.26.3-29.fc9.x86_64 Host arch: x86_64 Guest: Windows Vista Ultimate 64-bit QEMU command: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -std-vga -full-screen -smp 2 I've been running this guest on this host with kvm-75 without difficulty. kvm-76, built the same way that kvm-75 was (and on the same machine), fails to start my guest. The guest window is up, but the guest fails to complete startup. Command line output is: kvm_create_phys_mem: File existsset_vram_mapping: cannot allocate memory: File exists set_vram_mapping failed kvm: get_dirty_pages returned -2 The last line repeats hundreds of times. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-10-02 13:01 Message: can you please test the patch at http://glommer.net/band-aid.patch ? -- Comment By: Brian Jackson (iggy_cav) Date: 2008-09-30 14:06 Message: This was reported on the mailing list. It's a problem with sdl output. Not specific to any guest. Until the problem is fixed, I'd suggest using vnc output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2138166&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: x86: Silence various LAPIC-related host kernel messages
Jan Kiszka wrote: KVM-x86 dumps a lot of debug messages that have no meaning for normal operation: - INIT de-assertion is ignored - SIPIs are sent and received - APIC writes are unaligned or < 4 byte long (Windows Server 2003 triggers this on SMP) Degrade them to true debug messages, keeping the host kernel log clean for real problems. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] provide a kvm_qemu_memory_alias() function
Following the pattern we already do, provide a qemu_kvm wrapper to
the memory aliases x86 functions. Reason is that we don't want to have
references to the context spread over qemu.
The destroy alias function is completely removed from libkvm/libkvm.c,
since no one in the code base uses it directly.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/qemu-kvm-x86.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c
index 5daedd1..9390a40 100644
--- a/qemu/qemu-kvm-x86.c
+++ b/qemu/qemu-kvm-x86.c
@@ -27,6 +27,18 @@ static int kvm_has_msr_star;
static int lm_capable_kernel;
+int kvm_qemu_create_memory_alias(uint64_t phys_start,
+ uint64_t len,
+ uint64_t target_phys)
+{
+return kvm_create_memory_alias(kvm_context, phys_start, len, target_phys);
+}
+
+int kvm_qemu_destroy_memory_alias(uint64_t phys_start)
+{
+ return kvm_destroy_memory_alias(kvm_context, phys_start);
+}
+
int kvm_arch_qemu_create_context(void)
{
int i;
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] fix compilation with --disable-kvm
Currently, kvm is failing to build with --disable-kvm.
this patch fixes the issue.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/gdbstub.c | 15 ++-
qemu/hw/acpi.c |6 +-
qemu/hw/cirrus_vga.c |7 +++
qemu/monitor.c |6 --
4 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/qemu/gdbstub.c b/qemu/gdbstub.c
index d57cd61..d65f1cf 100644
--- a/qemu/gdbstub.c
+++ b/qemu/gdbstub.c
@@ -994,10 +994,12 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
addr = strtoull(p, (char **)&p, 16);
#if defined(TARGET_I386)
env->eip = addr;
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env->nip = addr;
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
#elif defined (TARGET_SPARC)
env->pc = addr;
env->npc = addr + 4;
@@ -1033,7 +1035,8 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
addr = strtoull(p, (char **)&p, 16);
#if defined(TARGET_I386)
env->eip = addr;
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env->nip = addr;
kvm_load_registers(env);
@@ -1078,7 +1081,8 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
}
break;
case 'g':
-kvm_save_registers(env);
+if (kvm_enabled())
+kvm_save_registers(env);
reg_size = cpu_gdb_read_registers(env, mem_buf);
memtohex(buf, mem_buf, reg_size);
put_packet(s, buf);
@@ -1088,7 +1092,8 @@ static int gdb_handle_packet(GDBState *s, CPUState *env,
const char *line_buf)
len = strlen(p) / 2;
hextomem((uint8_t *)registers, p, len);
cpu_gdb_write_registers(env, mem_buf, len);
-kvm_load_registers(env);
+if (kvm_enabled())
+kvm_load_registers(env);
put_packet(s, "OK");
break;
case 'm':
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 05f5dc0..a51fcb7 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -726,7 +726,11 @@ void qemu_system_cpu_hot_add(int cpu, int state)
{
CPUState *env;
-if ((state) && (!qemu_kvm_cpu_env(cpu))) {
+if (state
+#ifdef USE_KVM
+&& (!qemu_kvm_cpu_env(cpu))
+#endif
+) {
env = pc_new_cpu(cpu, model, 1);
if (!env) {
fprintf(stderr, "cpu %d creation failed\n", cpu);
diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index 4f3aef9..dac0731 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -2677,14 +2677,13 @@ static void kvm_update_vga_alias(CirrusVGAState *s, int
ok, int bank)
if (!s->aliases_enabled
|| base != s->aliased_bank_base[bank]
|| limit != s->aliased_bank_limit[bank]) {
- kvm_create_memory_alias(kvm_context,
- 0xa + bank * 0x8000,
- limit, base);
+ kvm_qemu_create_memory_alias(0xa + bank * 0x8000,
+ limit, base);
s->aliased_bank_base[bank] = base;
s->aliased_bank_limit[bank] = limit;
}
} else {
- kvm_destroy_memory_alias(kvm_context, 0xa + bank * 0x8000);
+ kvm_qemu_destroy_memory_alias(0xa + bank * 0x8000);
}
}
diff --git a/qemu/monitor.c b/qemu/monitor.c
index d6b3da6..97b5cbe 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -292,7 +292,8 @@ static CPUState *mon_get_cpu(void)
mon_set_cpu(0);
}
-kvm_save_registers(mon_cpu);
+if (kvm_enabled())
+kvm_save_registers(mon_cpu);
return mon_cpu;
}
@@ -320,7 +321,8 @@ static void do_info_cpus(void)
mon_get_cpu();
for(env = first_cpu; env != NULL; env = env->next_cpu) {
-kvm_save_registers(env);
+if (kvm_enabled())
+kvm_save_registers(env);
term_printf("%c CPU #%d:",
(env == mon_cpu) ? '*' : ' ',
env->cpu_index);
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] KVM failing to compile with --disable-kvm
Father Avi, is it better now? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
iommu external module
When userspace support for device assignment is merged, we will finally have full support for device assignment. Unfortunately, many users won't be able to test or use device assignment, since very few actually run development kernels. The first stable kernel with enough iommu support for kvm will be 2.6.28, released in about three months, and distros are even further away. We can fix this fairly simply by having an external module for the iommus, much like kvm itself. I don't think it should be too difficult, and it will provide a lot of testing to us, and important functionality for our users. Anyone willing to pick this up? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2106661 ] Fail to save restore and live migration
Bugs item #2106661, was opened at 2008-09-12 04:50 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2106661&group_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: Pending Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: Fail to save restore and live migration Initial Comment: Against latest kvm commit, kvm.git 2d7a06ff26576b1918dfe8e25ba4ffdfc24e and userspace.git 5925d8e58d1fa4668351b157d9635be016794c79, save restore and live migration will fail when save the guest. On qemu console, it will print "Could not start migration Migration failed! ret=0 error=102 migration failed (migration_init_file for /save_file failed)" And host console will print kvm_dirty_pages_log_change: Invalide argument. Previous commit kvm.git 2d7a06ff26576b1918dfe8e25ba4ffdfc24e, userspace.git ef703584f1f146d94b48354d2a6cb9f26fd37111 has no such issue. Reproduce steps: 1.use qcow based image to boot a guest: qemu-img create -b /share/xvs/img/app/ia32p_UP.img -f qcow2 /share/xvs/var/tmp1 qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:35:1c:97,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp1 2.ctrl+alt+2 switch to qemu monitor and save the guest migrate file:save_file -- >Comment By: Avi Kivity (avik) Date: 2008-10-02 15:41 Message: Should be fixed now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2106661&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 0/5] bios: >4G updates
Alex Williamson wrote: It works, so I pushed it out. Alex, can you rebase your bios patches on top of current HEAD? I updated and resent the first patch in the 4 patch follow-on to this one. The remaining 3 patches still apply cleanly. I think Sheng was going to send out a patch to better follow the SDM when changing the MTRRs, but the first 3 patches are independent of that. Thanks, Applied all, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESEND] VT-d: Fix iommu map page for mmio pages
Muli Ben-Yehuda wrote: On Thu, Oct 02, 2008 at 02:56:55PM +0300, Avi Kivity wrote: Han, Weidong wrote: From 61028d958dc7c57ee02de32ea89b025dccb9650d Mon Sep 17 00:00:00 2001 From: Weidong Han <[EMAIL PROTECTED]> Date: Thu, 25 Sep 2008 23:32:02 +0800 Subject: [PATCH] Map mmio pages into VT-d page table Assigned device could DMA to mmio pages, so also need to map mmio pages into VT-d page table. Well, Muli says at least on one machine this allows on guest to kill the host. What are we doing with this? If it's a hardware bug which is planned to be fixed (or is already fixed), great, but I need to know. Unfortunately I don't have access to the machine any more. We did spend some time perusing the PCIe spec on this point, and although it is pretty vague, the bottom line appears to be that peer-to-peer traffic (device-to-device traffic) is allowed. I'm fine with applying the patch. Okay, I applied the patch. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESEND] VT-d: Fix iommu map page for mmio pages
On Thu, Oct 02, 2008 at 02:56:55PM +0300, Avi Kivity wrote: > Han, Weidong wrote: >> From 61028d958dc7c57ee02de32ea89b025dccb9650d Mon Sep 17 00:00:00 2001 >> From: Weidong Han <[EMAIL PROTECTED]> >> Date: Thu, 25 Sep 2008 23:32:02 +0800 >> Subject: [PATCH] Map mmio pages into VT-d page table >> >> Assigned device could DMA to mmio pages, so also need to map mmio pages >> into VT-d page table. >> >> > > Well, Muli says at least on one machine this allows on guest to kill > the host. What are we doing with this? > > If it's a hardware bug which is planned to be fixed (or is already > fixed), great, but I need to know. Unfortunately I don't have access to the machine any more. We did spend some time perusing the PCIe spec on this point, and although it is pretty vague, the bottom line appears to be that peer-to-peer traffic (device-to-device traffic) is allowed. I'm fine with applying the patch. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESEND] VT-d: Fix iommu map page for mmio pages
Han, Weidong wrote: From 61028d958dc7c57ee02de32ea89b025dccb9650d Mon Sep 17 00:00:00 2001 From: Weidong Han <[EMAIL PROTECTED]> Date: Thu, 25 Sep 2008 23:32:02 +0800 Subject: [PATCH] Map mmio pages into VT-d page table Assigned device could DMA to mmio pages, so also need to map mmio pages into VT-d page table. Well, Muli says at least on one machine this allows on guest to kill the host. What are we doing with this? If it's a hardware bug which is planned to be fixed (or is already fixed), great, but I need to know. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: still not working with kvm-76 userspace but still working with kvm-71 userspace and kmod-76. what else can i do? What's the guest kernel? Is it updated relative to the madrake-10 release? I was able to install and run mandrake 10 a couple of weeks ago, so maybe this only happens together with an update. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] provide a kvm_qemu_memory_alias() function
Glauber Costa wrote:
On Wed, Oct 1, 2008 at 4:38 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
Glauber Costa wrote:
Following the pattern we already do, provide a qemu_kvm wrapper to
the memory aliases x86 functions. Reason is that we don't want to have
references to the context spread over qemu.
The destroy alias function is completely removed from libkvm/libkvm.c,
since no one in the code base uses it directly.
-int kvm_destroy_memory_alias(kvm_context_t kvm, uint64_t phys_start)
-{
- return kvm_create_memory_alias(kvm, phys_start, 0, 0);
-}
-
This exists so that readers don't have to wander why you're calling
kvm_create_memory_alias when you actually want to destroy one.
So what? I'm replacing it with a kvm_qemu_destroy... that does the
very same thing, in the very same way.
only difference is the presence/absence of context.
libkvm exists to provide a sane API to applications. Using
kvm_create_memory_alias() to destroy aliases is not a sane API.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] CPUID usage for interaction between Hypervisors and Linux.
Chris Wright wrote: * Anthony Liguori ([EMAIL PROTECTED]) wrote: And arguably, storing TSC frequency in CPUID is a terrible interface because the TSC frequency can change any time a guest is entered. It True for older hardware, newer hardware should fix this. I guess the point is, the are numbers that are easy to measure incorrectly in guest. Doesn't justify the whole thing.. It's not fixed for newer hardware. Larger systems still have multiple tsc frequencies. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Dor Laor <[EMAIL PROTECTED]> writes: > Sven Rudolph wrote: ... > > Trying a summary: When using virtio Ethernet and "-usb"; Windows > > leaves something (virtio Ethernet or USB ?) in a state that isn't > > reset by my reboot sequence (etherboot/pxegrub) and makes the next > > Windows boot hang. Booting Linux inbetween resets that state, and > > using the "-boot c" path does that too. ... > It seems like the virtio and the usb root hub share the same pci irq. Probably > on reboot > the usb root hub does not reset the irq status and just after boot the driver > gets into infnit loop. > Can you try to compile the following: > diff --git a/qemu/hw/usb-uhci.c b/qemu/hw/usb-uhci.c > index b90cf78..773ad54 100644 > --- a/qemu/hw/usb-uhci.c > +++ b/qemu/hw/usb-uhci.c > @@ -1098,6 +1098,7 @@ void usb_uhci_piix3_init(PCIBus *bus, int devfn) > s->frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s); > > uhci_reset(s); > + qemu_register_reset(uhci_reset, s); > > /* Use region 4 for consistency with real hardware. BSD guests seem > to rely on this. */ > @@ -1135,6 +1136,7 @@ void usb_uhci_piix4_init(PCIBus *bus, int devfn) > s->frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s); > > uhci_reset(s); > + qemu_register_reset(uhci_reset, s); > > /* Use region 4 for consistency with real hardware. BSD guests seem > to rely on this. */ This patch didn't help... > Alternatively you can try -no-kvm-irqchip ... but this option helps. I hope this is a useful hint for finding the origin of the problem. Thanks, Sven -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM Management : ConVirt 0.9.5 Released.
Hi Guys, We are pleased to announce ConVirt 0.9.5 which includes * drag and drop live migration for KVM * Storage Management and * some critical bug fixes For more information, please visit us at http://www.convirt.net/ Thanks ConVirt Team -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] KVM: Implement OR logic on guest shared IRQ line
[Oops, outlook even didn't notice that last mail don't have subject then send
it out...]
>From eab008da232cd9cc09dd8071bd15796c8e46f6bd Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 2 Oct 2008 14:21:06 +0800
Subject: [PATCH 2/2] KVM: Implement OR logic on guest shared IRQ line
Now IOAPIC and PIC treat every kvm_set_irq() as from one separate interrupt
source, so implement OR logic base on this.
Notice that the every caller should ensure that it would call kvm_set_irq()
only when the interrupt state of source is changing (also means call
kvm_set_irq() in pair).
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/i8259.c | 12 +++-
arch/x86/kvm/irq.c |6 +-
arch/x86/kvm/irq.h |1 +
arch/x86/kvm/x86.c |3 ---
virt/kvm/ioapic.c|9 +
virt/kvm/ioapic.h|1 +
6 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index 17e41e1..d2b05be 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -142,9 +142,19 @@ void kvm_pic_update_irq(struct kvm_pic *s)
void kvm_pic_set_irq(void *opaque, int irq, int level)
{
struct kvm_pic *s = opaque;
+ struct kvm_kpic_state *entry;
+ entry = &s->pics[irq >> 3];
if (irq >= 0 && irq < PIC_NUM_PINS) {
- pic_set_irq1(&s->pics[irq >> 3], irq & 7, level);
+ /* OR logic on level trig for sharing interrupt */
+ if (entry->elcr) {
+ s->irq_counts[irq] += (level == 1 ? 1 : -1);
+ ASSERT(s->irq_counts[irq] >= 0);
+ if (s->irq_counts[irq] != 0)
+ level = 1;
+ }
+
+ pic_set_irq1(entry, irq & 7, level);
pic_update_irq(s);
}
}
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 8c1b9c5..8999d9d 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -100,7 +100,11 @@ void __kvm_migrate_timers(struct kvm_vcpu *vcpu)
__kvm_migrate_pit_timer(vcpu);
}
-/* This should be called with the kvm->lock mutex held */
+/*
+ * The caller of kvm_set_irq() should hold kvm->lock mutex, and ensure
+ * that kvm_set_irq() was called in pair when asserting and deasserting with
+ * level trig interrupt source for the same irq.
+ */
void kvm_set_irq(struct kvm *kvm, int irq, int level)
{
/* Not possible to detect if the guest uses the PIC or the
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 9f157c9..ef9e828 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -60,6 +60,7 @@ struct kvm_kpic_state {
struct kvm_pic {
struct kvm_kpic_state pics[2]; /* 0 is master pic, 1 is slave pic */
+ int irq_counts[PIC_NUM_PINS];
irq_request_func *irq_request;
void *irq_request_opaque;
int output; /* intr from master PIC */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e685d48..71a0f81 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -144,9 +144,6 @@ static void kvm_assigned_dev_interrupt_work_handler(struct
work_struct *work)
kvm_put_kvm(assigned_dev->kvm);
}
-/* FIXME: Implement the OR logic needed to make shared interrupts on
- * this line behave properly
- */
static irqreturn_t kvm_assigned_dev_intr(int irq, void *dev_id)
{
struct kvm_assigned_dev_kernel *assigned_dev =
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index c8f939c..d9526e0 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -275,6 +275,15 @@ void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int
irq, int level)
if (irq >= 0 && irq < IOAPIC_NUM_PINS) {
entry = ioapic->redirtbl[irq];
+
+ /* OR logic on level trig for sharing interrupt */
+ if (entry.fields.trig_mode == 1) {
+ ioapic->irq_counts[irq] += (level == 1 ? 1 : -1);
+ ASSERT(ioapic->irq_counts[irq] >= 0);
+ if (ioapic->irq_counts[irq] != 0)
+ level = 1;
+ }
+
level ^= entry.fields.polarity;
if (!level)
ioapic->irr &= ~mask;
diff --git a/virt/kvm/ioapic.h b/virt/kvm/ioapic.h
index b52732f..6ed7dc7 100644
--- a/virt/kvm/ioapic.h
+++ b/virt/kvm/ioapic.h
@@ -56,6 +56,7 @@ struct kvm_ioapic {
u8 dest_id;
} fields;
} redirtbl[IOAPIC_NUM_PINS];
+ int irq_counts[IOAPIC_NUM_PINS];
struct kvm_io_device dev;
struct kvm *kvm;
void (*ack_notifier)(void *opaque, int irq);
--
1.5.3
0002-KVM-Implement-OR-logic-on-guest-shared-IRQ-line.patch
Description: 0002-KVM-Implement-OR-logic-on-guest-shared-IRQ-line.patch
[no subject]
>From eab008da232cd9cc09dd8071bd15796c8e46f6bd Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 2 Oct 2008 14:21:06 +0800
Subject: [PATCH 2/2] KVM: Implement OR logic on guest shared IRQ line
Now IOAPIC and PIC treat every kvm_set_irq() as from one separate interrupt
source, so implement OR logic base on this.
Notice that the every caller should ensure that it would call kvm_set_irq()
only when the interrupt state of source is changing (also means call
kvm_set_irq() in pair).
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/i8259.c | 12 +++-
arch/x86/kvm/irq.c |6 +-
arch/x86/kvm/irq.h |1 +
arch/x86/kvm/x86.c |3 ---
virt/kvm/ioapic.c|9 +
virt/kvm/ioapic.h|1 +
6 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index 17e41e1..d2b05be 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -142,9 +142,19 @@ void kvm_pic_update_irq(struct kvm_pic *s)
void kvm_pic_set_irq(void *opaque, int irq, int level)
{
struct kvm_pic *s = opaque;
+ struct kvm_kpic_state *entry;
+ entry = &s->pics[irq >> 3];
if (irq >= 0 && irq < PIC_NUM_PINS) {
- pic_set_irq1(&s->pics[irq >> 3], irq & 7, level);
+ /* OR logic on level trig for sharing interrupt */
+ if (entry->elcr) {
+ s->irq_counts[irq] += (level == 1 ? 1 : -1);
+ ASSERT(s->irq_counts[irq] >= 0);
+ if (s->irq_counts[irq] != 0)
+ level = 1;
+ }
+
+ pic_set_irq1(entry, irq & 7, level);
pic_update_irq(s);
}
}
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 8c1b9c5..8999d9d 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -100,7 +100,11 @@ void __kvm_migrate_timers(struct kvm_vcpu *vcpu)
__kvm_migrate_pit_timer(vcpu);
}
-/* This should be called with the kvm->lock mutex held */
+/*
+ * The caller of kvm_set_irq() should hold kvm->lock mutex, and ensure
+ * that kvm_set_irq() was called in pair when asserting and deasserting with
+ * level trig interrupt source for the same irq.
+ */
void kvm_set_irq(struct kvm *kvm, int irq, int level)
{
/* Not possible to detect if the guest uses the PIC or the
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 9f157c9..ef9e828 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -60,6 +60,7 @@ struct kvm_kpic_state {
struct kvm_pic {
struct kvm_kpic_state pics[2]; /* 0 is master pic, 1 is slave pic */
+ int irq_counts[PIC_NUM_PINS];
irq_request_func *irq_request;
void *irq_request_opaque;
int output; /* intr from master PIC */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e685d48..71a0f81 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -144,9 +144,6 @@ static void kvm_assigned_dev_interrupt_work_handler(struct
work_struct *work)
kvm_put_kvm(assigned_dev->kvm);
}
-/* FIXME: Implement the OR logic needed to make shared interrupts on
- * this line behave properly
- */
static irqreturn_t kvm_assigned_dev_intr(int irq, void *dev_id)
{
struct kvm_assigned_dev_kernel *assigned_dev =
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index c8f939c..d9526e0 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -275,6 +275,15 @@ void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int
irq, int level)
if (irq >= 0 && irq < IOAPIC_NUM_PINS) {
entry = ioapic->redirtbl[irq];
+
+ /* OR logic on level trig for sharing interrupt */
+ if (entry.fields.trig_mode == 1) {
+ ioapic->irq_counts[irq] += (level == 1 ? 1 : -1);
+ ASSERT(ioapic->irq_counts[irq] >= 0);
+ if (ioapic->irq_counts[irq] != 0)
+ level = 1;
+ }
+
level ^= entry.fields.polarity;
if (!level)
ioapic->irr &= ~mask;
diff --git a/virt/kvm/ioapic.h b/virt/kvm/ioapic.h
index b52732f..6ed7dc7 100644
--- a/virt/kvm/ioapic.h
+++ b/virt/kvm/ioapic.h
@@ -56,6 +56,7 @@ struct kvm_ioapic {
u8 dest_id;
} fields;
} redirtbl[IOAPIC_NUM_PINS];
+ int irq_counts[IOAPIC_NUM_PINS];
struct kvm_io_device dev;
struct kvm *kvm;
void (*ack_notifier)(void *opaque, int irq);
--
1.5.3
0002-KVM-Implement-OR-logic-on-guest-shared-IRQ-line.patch
Description: 0002-KVM-Implement-OR-logic-on-guest-shared-IRQ-line.patch
[PATCH 1/2] KVM: Separate interrupt sources
>From e6b784985c14afe9805bfc8706858884b0259ab5 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 2 Oct 2008 14:20:22 +0800
Subject: [PATCH 1/2] KVM: Separate interrupt sources
Keep a record of current interrupt state before update, and don't
assert/deassert repeatly. So that every caller of kvm_set_irq() can be identify
as a separate interrupt sources for IOAPIC/PIC to implement logical OR of level
trig interrupts on one IRQ line.
Notice that userspace devices are treated as one device for each IRQ line. The
correctness of sharing interrupt for each IRQ line should be ensured by
userspace program (QEmu).
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 25 +
include/linux/kvm_host.h |3 +++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ad7a227..e685d48 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -135,8 +135,11 @@ static void kvm_assigned_dev_interrupt_work_handler(struct
work_struct *work)
* finer-grained lock, update this
*/
mutex_lock(&assigned_dev->kvm->lock);
- kvm_set_irq(assigned_dev->kvm,
- assigned_dev->guest_irq, 1);
+ if (assigned_dev->irq_state == 0) {
+ kvm_set_irq(assigned_dev->kvm,
+ assigned_dev->guest_irq, 1);
+ assigned_dev->irq_state = 1;
+ }
mutex_unlock(&assigned_dev->kvm->lock);
kvm_put_kvm(assigned_dev->kvm);
}
@@ -165,7 +168,10 @@ static void kvm_assigned_dev_ack_irq(struct
kvm_irq_ack_notifier *kian)
dev = container_of(kian, struct kvm_assigned_dev_kernel,
ack_notifier);
- kvm_set_irq(dev->kvm, dev->guest_irq, 0);
+ if (dev->irq_state == 1) {
+ kvm_set_irq(dev->kvm, dev->guest_irq, 0);
+ dev->irq_state = 0;
+ }
enable_irq(dev->host_irq);
}
@@ -1993,7 +1999,18 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
if (irqchip_in_kernel(kvm)) {
mutex_lock(&kvm->lock);
- kvm_set_irq(kvm, irq_event.irq, irq_event.level);
+ /*
+* Take one IRQ line as from one device, shared IRQ
+* line should also be handled in the userspace before
+* use KVM_IRQ_LINE ioctl to change IRQ line state.
+*/
+ if (kvm->userspace_intrsource_states[irq_event.irq]
+ != irq_event.level) {
+ kvm_set_irq(kvm, irq_event.irq,
+ irq_event.level);
+ kvm->userspace_intrsource_states[irq_event.irq]
+ = irq_event.level;
+ }
mutex_unlock(&kvm->lock);
r = 0;
}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 73b7c52..8c2a504 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -129,6 +129,8 @@ struct kvm {
unsigned long mmu_notifier_seq;
long mmu_notifier_count;
#endif
+
+ int userspace_intrsource_states[KVM_IOAPIC_NUM_PINS];
};
/* The guest did something we don't support. */
@@ -303,6 +305,7 @@ struct kvm_assigned_dev_kernel {
int host_irq;
int guest_irq;
int irq_requested;
+ int irq_state;
struct pci_dev *dev;
struct kvm *kvm;
};
--
1.5.3
0001-KVM-Separate-interrupt-sources.patch
Description: 0001-KVM-Separate-interrupt-sources.patch
[RFC][PATCH 0/2] Fix guest shared interrupt with in-kernel irqchip
To deal with guest shared interrupt bug in in-kernel irqchip, we should: 1. Identify each level trig interrupt source. 2. Implement logical OR on the same IRQ line for each interrupt source. Here I chose a simple method: the caller of kvm_set_irq() has responsiblity to identify interrupt sources, and IOAPIC/PIC ensure logical OR on IRQ line. The alternative method of identify can be: a process to request/allocate/free device identity, then kvm_set_irq() has responsibility to identify interrupt sources. But I think it's too complicate and unnecessary, for the caller of set_irq() should aware of the IRQ state. The patch treats all userspace devices as one source. This have been ensured by QEmu, which would ensure logical OR on IRQ line if IRQ line is sharing in userspace. Comments are welcome! And patches are untested, due to our boxes are down during the holiday(and my Linux Desktop in the company also down, have to post patch with outlook)... Thanks! -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
