[ kvm-Bugs-2405145 ] kvm-80 AMD unknown symbols
Bugs item #2405145, was opened at 2008-12-07 20:39 Message generated for change (Comment added) made by mishehu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2405145&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: kernel Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Mishehu Mashehu (mishehu) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-80 AMD unknown symbols Initial Comment: System is an Athlon64 Socket AM2, 1 dual core CPU, host OS is Slamd64 12.1 running kernel 2.6.27.7 (vanilla from kernel.org patched with Edward Shishkin's reiser4-for-2.6.27.patch). Built kvm-80 using the following slackbuild script: /* Script starts */ #!/bin/sh PKGNAM=kvm VERSION=80 BUILD=1 TMP=/usr/local/src/kvm-80/tmp . /etc/pkghelpers pkghelpers_env cd $TMP tar xfv $CWD/$PKGNAM-$VERSION.tar.gz || exit 1 cd $PKGNAM-$VERSION ./configure \ --prefix=/usr \ #--with-patched-kernel \ --enable-mixemu \ --audio-drv-list=alsa \ --disable-gcc-check make -j5 || exit 1 make install DESTDIR=$PKG cd $PKG mv usr/share/man usr/man mkdir install cat $CWD/slack-desc > install/slack-desc pkghelpers_fixup pkghelpers_makepkg /* script ends */ Everybody builds fine (minus an occasional compiler warning), and I end up with /lib/modules/2.6.27.7/extra/kvm.ko , kvm-amd.ko, and kvm-intel.ko after I install the newly created slackpack. However, whenever I attempt to modprobe the modules, I get the following: kvm: Unknown symbol intel_iommu_domain_alloc kvm: Unknown symbol intel_iommu_detach_dev kvm: Unknown symbol intel_iommu_page_mapping kvm: Unknown symbol intel_iommu_context_mapping kvm: Unknown symbol intel_iommu_iova_to_pfn kvm: Unknown symbol intel_iommu_domain_exit kvm_amd: Unknown symbol kvm_exit kvm_amd: Unknown symbol kvm_init kvm_amd: Unknown symbol kvm_enable_efer_bits kvm_amd: Unknown symbol kvm_timer_intr_post kvm_amd: Unknown symbol kvm_get_msr_common kvm_amd: Unknown symbol kvm_vcpu_uninit kvm_amd: Unknown symbol kvm_emulate_halt kvm_amd: Unknown symbol kvm_lapic_find_highest_irr kvm_amd: Unknown symbol kvm_task_switch kvm_amd: Unknown symbol kvm_enable_tdp kvm_amd: Unknown symbol kvm_disable_tdp kvm_amd: Unknown symbol kvm_queue_exception kvm_amd: Unknown symbol emulate_instruction kvm_amd: Unknown symbol fx_init kvm_amd: Unknown symbol kvm_cpu_has_interrupt kvm_amd: Unknown symbol kvm_lapic_get_cr8 kvm_amd: Unknown symbol kvm_get_cr8 kvm_amd: Unknown symbol kvm_x86_ops kvm_amd: Unknown symbol kvm_vcpu_cache kvm_amd: Unknown symbol kvm_emulate_hypercall kvm_amd: Unknown symbol load_pdptrs kvm_amd: Unknown symbol kvm_handle_fault_on_reboot kvm_amd: Unknown symbol kvm_mmu_unprotect_page_virt kvm_amd: Unknown symbol kvm_get_cs_db_l_bits kvm_amd: Unknown symbol kvm_mmu_page_fault kvm_amd: Unknown symbol kvm_lapic_set_tpr kvm_amd: Unknown symbol kvm_mmu_reset_context kvm_amd: Unknown symbol kvm_queue_exception_e kvm_amd: Unknown symbol kvm_emulate_cpuid kvm_amd: Unknown symbol kvm_vcpu_init kvm_amd: Unknown symbol kvm_set_msr_common kvm_amd: Unknown symbol kvm_mmu_load kvm_amd: Unknown symbol kvm_cpu_get_interrupt kvm_amd: Unknown symbol kvm_emulate_pio I have tried multiple fresh reconfiguration/recompilations of the kernel and turn up the same result. Since everything else appears fine up to this point, and since nobody on the irc channel could tell what is the issue, it *appears* to be a bug. -- >Comment By: Mishehu Mashehu (mishehu) Date: 2008-12-08 00:29 Message: I managed to stumble upon a solution for this. Although one of the fellow users on the #kvm channel didn't think it was the CONFIG_DMAR in the kernel, I came across another posting on a newsgroup. I have since disabled DMAR and I have been able to successfully been able to insert the module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2405145&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 1/2] kvm: use modern cpumask primitives, no cpumask_t on stack
On Monday 08 December 2008 02:44:00 Avi Kivity wrote:
> Avi Kivity wrote:
> > Rusty Russell wrote:
> >> We're getting rid on on-stack cpumasks for large NR_CPUS.
> >>
> >> 1) Use cpumask_var_t and alloc_cpumask_var (a noop normally). Fallback
> >>code is inefficient but never happens in practice.
> >
> > Wow, code duplication from Rusty. Things must be bad.
> >
> > Since we're in a get_cpu() here, how about a per_cpu static cpumask
> > instead? I don't mind the inefficient fallback, just the duplication.
> >
>
> Btw, for the general case, instead of forcing everyone to duplicate, how
> about:
>
> cpumask_var_t cpus;
>
> with_cpumask(cpus) {
>... code to populate cpus
>smp_call_function_some(...);
> } end_with_cpumask(cpus);
>
> Where with_cpumask() allocates cpus, and uses a mutex + static fallback
> on failure.
I'd prefer not to hide deadlocks that way :(
I'll re-battle with that code to neaten it. There are only a few places
which have these kind of issues.
Thanks,
Rusty.
--
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] kvm: use cpumask_var_t for cpus_hardware_enabled
On Monday 08 December 2008 02:25:50 Avi Kivity wrote: > Rusty Russell wrote: > > This changes cpus_hardware_enabled from a cpumask_t to a cpumask_var_t: > > equivalent for CONFIG_CPUMASKS_OFFSTACK=n, otherwise dynamically allocated. > > > > > > -static cpumask_t cpus_hardware_enabled; > > +static cpumask_var_t cpus_hardware_enabled > > This isn't on stack, so it isn't buying us anything. It's the CONFIG_NR_CPUS=4096 but nr_cpu_ids=4 case which we win using dynamic allocation. Gotta love distribution kernels. > Is the plan to drop cpumask_t? Yes. And undefine 'struct cpumask' if CONFIG_CPUMASK_OFFSTACK. That will stop assignment and on-stack declarations for all but the most determined. > If so, we're penalizing non-stack users > by forcing them to go through another pointer (and cacheline). Not quite. If !CONFIG_CPUMASK_OFFSTACK, cpumask_var_t == cpumask_t[1]. Blame Linus :) Cheers, Rusty. -- 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-2405145 ] kvm-80 AMD unknown symbols
Bugs item #2405145, was opened at 2008-12-07 20:39 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=2405145&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: kernel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mishehu Mashehu (mishehu) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-80 AMD unknown symbols Initial Comment: System is an Athlon64 Socket AM2, 1 dual core CPU, host OS is Slamd64 12.1 running kernel 2.6.27.7 (vanilla from kernel.org patched with Edward Shishkin's reiser4-for-2.6.27.patch). Built kvm-80 using the following slackbuild script: /* Script starts */ #!/bin/sh PKGNAM=kvm VERSION=80 BUILD=1 TMP=/usr/local/src/kvm-80/tmp . /etc/pkghelpers pkghelpers_env cd $TMP tar xfv $CWD/$PKGNAM-$VERSION.tar.gz || exit 1 cd $PKGNAM-$VERSION ./configure \ --prefix=/usr \ #--with-patched-kernel \ --enable-mixemu \ --audio-drv-list=alsa \ --disable-gcc-check make -j5 || exit 1 make install DESTDIR=$PKG cd $PKG mv usr/share/man usr/man mkdir install cat $CWD/slack-desc > install/slack-desc pkghelpers_fixup pkghelpers_makepkg /* script ends */ Everybody builds fine (minus an occasional compiler warning), and I end up with /lib/modules/2.6.27.7/extra/kvm.ko , kvm-amd.ko, and kvm-intel.ko after I install the newly created slackpack. However, whenever I attempt to modprobe the modules, I get the following: kvm: Unknown symbol intel_iommu_domain_alloc kvm: Unknown symbol intel_iommu_detach_dev kvm: Unknown symbol intel_iommu_page_mapping kvm: Unknown symbol intel_iommu_context_mapping kvm: Unknown symbol intel_iommu_iova_to_pfn kvm: Unknown symbol intel_iommu_domain_exit kvm_amd: Unknown symbol kvm_exit kvm_amd: Unknown symbol kvm_init kvm_amd: Unknown symbol kvm_enable_efer_bits kvm_amd: Unknown symbol kvm_timer_intr_post kvm_amd: Unknown symbol kvm_get_msr_common kvm_amd: Unknown symbol kvm_vcpu_uninit kvm_amd: Unknown symbol kvm_emulate_halt kvm_amd: Unknown symbol kvm_lapic_find_highest_irr kvm_amd: Unknown symbol kvm_task_switch kvm_amd: Unknown symbol kvm_enable_tdp kvm_amd: Unknown symbol kvm_disable_tdp kvm_amd: Unknown symbol kvm_queue_exception kvm_amd: Unknown symbol emulate_instruction kvm_amd: Unknown symbol fx_init kvm_amd: Unknown symbol kvm_cpu_has_interrupt kvm_amd: Unknown symbol kvm_lapic_get_cr8 kvm_amd: Unknown symbol kvm_get_cr8 kvm_amd: Unknown symbol kvm_x86_ops kvm_amd: Unknown symbol kvm_vcpu_cache kvm_amd: Unknown symbol kvm_emulate_hypercall kvm_amd: Unknown symbol load_pdptrs kvm_amd: Unknown symbol kvm_handle_fault_on_reboot kvm_amd: Unknown symbol kvm_mmu_unprotect_page_virt kvm_amd: Unknown symbol kvm_get_cs_db_l_bits kvm_amd: Unknown symbol kvm_mmu_page_fault kvm_amd: Unknown symbol kvm_lapic_set_tpr kvm_amd: Unknown symbol kvm_mmu_reset_context kvm_amd: Unknown symbol kvm_queue_exception_e kvm_amd: Unknown symbol kvm_emulate_cpuid kvm_amd: Unknown symbol kvm_vcpu_init kvm_amd: Unknown symbol kvm_set_msr_common kvm_amd: Unknown symbol kvm_mmu_load kvm_amd: Unknown symbol kvm_cpu_get_interrupt kvm_amd: Unknown symbol kvm_emulate_pio I have tried multiple fresh reconfiguration/recompilations of the kernel and turn up the same result. Since everything else appears fine up to this point, and since nobody on the irc channel could tell what is the issue, it *appears* to be a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2405145&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-1971512 ] failure to migrate guests with more than 4GB of RAM
Bugs item #1971512, was opened at 2008-05-24 21:45 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1971512&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: Closed Resolution: Fixed Priority: 3 Private: No Submitted By: Marcelo Tosatti (mtosatti) Assigned to: Anthony Liguori (aliguori) Summary: failure to migrate guests with more than 4GB of RAM Initial Comment: The migration code assumes linear "phys_ram_base": [EMAIL PROTECTED] kvm-userspace.tip]# qemu/x86_64-softmmu/qemu-system-x86_64 -hda /root/images/marcelo5-io-test.img -m 4097 -net nic,model=rtl8139 -net tap,script=/root/iptables/ifup -incoming tcp://0:/ audit_log_user_command(): Connection refused audit_log_user_command(): Connection refused migration: memory size mismatch: recv 22032384 mine 4316999680 migrate_incoming_fd failed (rc=232) -- >Comment By: SourceForge Robot (sf-robot) Date: 2008-12-08 02:22 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-25 05:52 Message: I tried latest commit, userspace.git 6e63ba19476753595e508713eb9daf559dc50bf6 with a 64-bit RHEL5.1 Guest. My host kernel is 2.6.26.2. And My host has 8GB memory and 4GB swap. Guest can be live migrated, but after that, guest will call trace. Maybe we can have a check with each other's environment. My steps as following: 1. qemu-system-x86_64 -incoming tcp:localhost: -m 4096 -net nic,macaddr=00:16:3e:44:1a:a6,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/rhel5u1.img 2. qemu-system-x86_64 -m 4096 -net nic,macaddr=00:16:3e:44:1a:a6,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/rhel5u1.img 3. In qemu console, type "migrate tcp:localhost:" The call trace messages in guest: ### Kernel BUG at block/elevator.c:560 invalid opcode: [1] SMP last sysfs file: /block/hda/removable CPU 0 Modules linked in: ipv6 autofs4 hidp rfcomm l2cap bluetooth sunrpc iscsi_tcp ib_iser libiscsi scsi_transport_iscsi rdma_ucm ib_ucm ib_srp ib_sdp rdma_cm ib_cm iw_cm ib_addr ib_local_sa ib_ipoib ib_sa ib_uverbs ib_umad ib_mad ib_core dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec i2c_core button battery asus_acpi acpi_memhotplug ac lp floppy pcspkr serio_raw 8139cp 8139too parport_pc parport mii ide_cd cdrom ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, comm: swapper Not tainted 2.6.18-53.el5 #1 RIP: 0010:[] [] elv_dequeue_request+0x8/0x3c RSP: 0018:8040ddc0 EFLAGS: 00010046 RAX: 0001 RBX: 81011381b398 RCX: RDX: 81011381b398 RSI: 81011381b398 RDI: 81011fb912c0 RBP: 804abe18 R08: 80304108 R09: 0012 R10: 0022 R11: R12: R13: 0001 R14: 0086 R15: 8040deb8 FS: () GS:80396000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2ad6f4d0 CR3: 0001126cc000 CR4: 06e0 Process swapper (pid: 0, threadinfo 803c6000, task 802dcae0) Stack: 8000ae3c 804abe18 804abe50 804abd00 0246 8003ba73 8003ba0c 804abe18 81011fbe5800 8000d2a5 81011fb8c5c0 Call Trace: [] ide_end_request+0xc6/0xfc [] ide_dma_intr+0x67/0xab [] ide_dma_intr+0x0/0xab [] ide_intr+0x16f/0x1df [] handle_IRQ_event+0x29/0x58 [] __do_IRQ+0xa4/0x105 [] do_IRQ+0xe7/0xf5 [] ret_from_intr+0x0/0xa [] __do_softirq+0x53/0xd5 [] call_softirq+0x1c/0x28 [] do_softirq+0x2c/0x85 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_kernel+0x220/0x225 [] _sinittext+0x237/0x23e Code: 0f 0b 68 25 50 29 80 c2 30 02 48 8b 46 08 48 89 42 08 48 89 RIP [] elv_dequeue_request+0x8/0x3c RSP <0>Kernel panic - not syncing: Fatal exception BUG: warning at kernel/panic.c:137/panic() (Not tainted) Call Trace: [] panic+0x1e3/0x1f4 [] do_unblank_screen+0x1b/0x132 [] oops_end+0x51/0x53 [] die+0x3a/0x44 [] do_invalid_op+0xad/0xb7 [] elv_dequeue_request+0x8/0x3c [] do_timer+0x2e8/0x53c [] main_timer_handler+0x23d/0x3f4 [] error_exit+0x0/0x84 [] elv_dequeue_request+0x8/0x3c [] ide_end_request+0xc6/0xfc [] ide_dma_intr+0x67/0xab [] ide_dma_intr+0x0/0xab [] ide_intr+0x16f/0x1df
[ kvm-Bugs-1978070 ] Launching KVM freezes the system
Bugs item #1978070, was opened at 2008-05-29 16:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1978070&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: amd Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Edo Monticelli (emonticel) Assigned to: Nobody/Anonymous (nobody) Summary: Launching KVM freezes the system Initial Comment: Every time kvm is launched, the qemu window opens. Then, after a few seconds, the whole system(Ubuntu-8.04) freezes or reboot. Tried the ubuntu repository version(kvm-62) and the kvm-69 version, whitout any significant difference. Tried different guests, Ubuntu(32/64 bit), Gentoo(32), Windows XP, but none is alive for more than 5-6 seconds. I have a Dell latitude D531 laptop with Ubuntu-8.04 (32bit i686 version) and the Ubuntu standard kernel: Linux edos 2.6.24-17-generic #1 SMP Thu May 29 00:18:56 CEST 2008 i686 GNU/Linux AMD Turion CPU: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 launching with: qemu-system-x86_64 -hda /home/Debian.img tried the options -no-kvm-irqchip or -no-kvm-pit but no effects. with -no-kvm it works. I compiled with -DDEBUG option and attached the resluting file. -- >Comment By: SourceForge Robot (sf-robot) Date: 2008-12-08 02:22 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Avi Kivity (avik) Date: 2008-11-23 19:20 Message: Does this still happen with kvm-78? Please try the latest BIOS update from the box vendor. -- Comment By: Edo Monticelli (emonticel) Date: 2008-06-06 13:28 Message: Logged In: YES user_id=2102037 Originator: YES No, it appeans ANYTIME I try to launch kvm. Tried various images. Also tried 2.6.25.4 kernel from kernel.org without success. I can follow any suggestion to get more debug output... -- Comment By: Anthony Liguori (aliguori) Date: 2008-06-05 21:55 Message: Logged In: YES user_id=120449 Originator: NO Does this happen after suspending? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1978070&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-2186151 ] qemu/qemu-kvm.c:356 SegmentCache breaks kvm-ia64 building
Bugs item #2186151, was opened at 2008-10-22 05:46 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2186151&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Zhang Jingke (zhangjingke) Assigned to: Nobody/Anonymous (nobody) Summary: qemu/qemu-kvm.c:356 SegmentCache breaks kvm-ia64 building Initial Comment: We found recently kvm-ia64 building was broken by the error in qemu/qemu-kvm.c. Those codes should be special for x86 side. Detail error info are: == /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:356: error: SegmentCache undeclared (first use in this function) /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:356: error: (Each undeclared identifier is reported only once /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:356: error: for each function it appears in.) /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:356: error: expected ; before cs /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:362: error: CPUIA64State has no member named segs /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:362: error: R_CS undeclared (first use in this function) /home/build/kvm-build/kvm-userspace/qemu/qemu-kvm.c:362: error: cs undeclared (first use in this function) make[2]: *** [qemu-kvm.o] Error 1 make[2]: Leaving directory `/home/build/kvm-build/kvm-userspace/qemu/ia64-softmmu' make[1]: *** [subdir-ia64-softmmu] Error 2 make[1]: Leaving directory `/home/build/kvm-build/kvm-userspace/qemu' make: *** [qemu] Error 2 -- >Comment By: SourceForge Robot (sf-robot) Date: 2008-12-08 02:22 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Avi Kivity (avik) Date: 2008-11-23 19:10 Message: Should be fixed now. -- Comment By: Zhang Jingke (zhangjingke) Date: 2008-10-22 05:53 Message: Add some more information: Userspace Commit: 2a433458f6f7ba93328bfd17c9b678b9180daf94 Kernel-ia64 Commit:d0ea17370a66375634986788cff333ab9610ed9f Host Kernel Version: 2.6.27-rc9 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2186151&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-2137862 ] Linux kernels with CONFIG_KVM_GUEST are broken on kvm-76
Bugs item #2137862, was opened at 2008-09-30 09:36 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2137862&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: kernel Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Michael Zhidovinov (mzhidovinov) Assigned to: Nobody/Anonymous (nobody) Summary: Linux kernels with CONFIG_KVM_GUEST are broken on kvm-76 Initial Comment: Kernels compiled with CONFIG_KVM_GUEST (e.g. 2.6.26/27 kernels from Fedora10/rawhide or Ubuntu 8.10) breaks in mysterious ways in early userspace. Host is x86_64 Intel's Core2 (Xeon 5138) with kernel from kvm git. Guests are both x86_64 and i386. Kernels with CONFIG_KVM_GUEST not set are fine. -- >Comment By: SourceForge Robot (sf-robot) Date: 2008-12-08 02:22 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Avi Kivity (avik) Date: 2008-11-23 19:13 Message: Should be fixed now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2137862&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-2217430 ] Host crash in kvm:unsync_walk_fn with kvm-78
Bugs item #2217430, was opened at 2008-11-03 00:01 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2217430&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: libkvm Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Host crash in kvm:unsync_walk_fn with kvm-78 Initial Comment: Built and installed kvm-78 today. Launched vista, ran several network and app tests on the guest and then walked away. The host Oops'ed sometime an hour or so later. Note that the last stable kvm version with this host/guest combo was kvm-75. Host: FC9 2.6.26.6-79.fc9.x86_64 Arch: x86_64 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Guest: Windows Vista Ultimate 64 Cmd: 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 -vga std -full-screen -smp 2 -soundhw all Nov 2 18:17:55 jrr-d830 kernel: BUG: unable to handle kernel NULL pointer dereference at 0051 Nov 2 18:17:55 jrr-d830 kernel: IP: [] :kvm:unsync_walk_fn+0x4/0x17 Nov 2 18:17:55 jrr-d830 kernel: PGD dcde0067 PUD b6490067 PMD 0 Nov 2 18:17:55 jrr-d830 kernel: Oops: 0002 [1] SMP Nov 2 18:17:55 jrr-d830 kernel: CPU 1 Nov 2 18:17:55 jrr-d830 kernel: Modules linked in: tun kvm_intel kvm bridge fuse sunrpc ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table loop dm_multipath nvidia(P) snd_hda_intel sr_mod snd_seq_dummy cdrom snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device ata_generic snd_pcm_oss dcdbas pcspkr ata_piix snd_mixer_oss joydev i2c_i801 snd_pcm sg video snd_timer output firewire_ohci snd_page_alloc snd_hwdep firewire_core bay snd pata_acpi tg3 i2c_core wmi crc_itu_t yenta_socket soundcore ssb rsrc_nonstatic battery ac iTCO_wdt iTCO_vendor_support dm_snapshot dm_zero dm_mirror dm_log dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Nov 2 18:17:55 jrr-d830 kernel: Pid: 5084, comm: qemu-system-x86 Tainted: P 2.6.26.6-79.fc9.x86_64 #1 Nov 2 18:17:55 jrr-d830 kernel: RIP: 0010:[] [] :kvm:unsync_walk_fn+0x4/0x17 Nov 2 18:17:55 jrr-d830 kernel: RSP: 0018:8100b646f978 EFLAGS: 00010202 Nov 2 18:17:55 jrr-d830 kernel: RAX: 00b3a1d8 RBX: RCX: 0005bc1c Nov 2 18:17:55 jrr-d830 kernel: RDX: e200 RSI: RDI: Nov 2 18:17:55 jrr-d830 kernel: RBP: 8100b646f9b8 R08: R09: 0040 Nov 2 18:17:55 jrr-d830 kernel: R10: R11: R12: 0008 Nov 2 18:17:55 jrr-d830 kernel: R13: 81002f02d840 R14: a0b68ab4 R15: 8100b647 Nov 2 18:17:55 jrr-d830 kernel: FS: 4246c950() GS:81011fc04880() knlGS: Nov 2 18:17:55 jrr-d830 kernel: CS: 0010 DS: 002b ES: 002b CR0: 8005003b Nov 2 18:17:55 jrr-d830 kernel: CR2: 0051 CR3: dcd0f000 CR4: 26e0 Nov 2 18:17:55 jrr-d830 kernel: DR0: DR1: DR2: Nov 2 18:17:55 jrr-d830 kernel: DR3: DR6: 0ff0 DR7: 0400 Nov 2 18:17:55 jrr-d830 kernel: Process qemu-system-x86 (pid: 5084, threadinfo 8100b646e000, task 81010d8dad40) Nov 2 18:17:55 jrr-d830 kernel: Stack: 8100b646f9b8 a0b689ce 81002f02d818 8100259545a0 Nov 2 18:17:55 jrr-d830 kernel: 8100b647 9b9aa063 0061 0003 Nov 2 18:17:55 jrr-d830 kernel: 8100b646fa18 a0b69ce5 8100b646fa48 01ff8108cc14 Nov 2 18:17:55 jrr-d830 kernel: Call Trace: Nov 2 18:17:55 jrr-d830 kernel: [] ? :kvm:mmu_parent_walk+0x97/0xd5 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm:set_spte+0x358/0x3e8 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm:mmu_set_spte+0xe1/0x2bd Nov 2 18:17:55 jrr-d830 kernel: [] :kvm:paging64_shadow_walk_entry+0x9e/0x1c0 Nov 2 18:17:55 jrr-d830 kernel: [] ? __up_read+0x7a/0x85 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm:walk_shadow+0x8c/0xb1 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm:paging64_page_fault+0x1a8/0x201 Nov 2 18:17:55 jrr-d830 kernel: [] ? :kvm:mmu_free_roots+0x3f/0xf6 Nov 2 18:17:55 jrr-d830 kernel: [] ? :kvm:paging64_shadow_walk_entry+0x0/0x1c0 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm:kvm_mmu_page_fault+0x1a/0x86 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm_intel:handle_exception+0x1d8/0x2b3 Nov 2 18:17:55 jrr-d830 kernel: [] :kvm_intel:kvm_handle_exit+0x219/0x23b Nov 2 18:17:55 jrr-
[ kvm-Bugs-2405061 ] kvm-80: virtio networking broken
Bugs item #2405061, was opened at 2008-12-08 11:07 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=2405061&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: libkvm Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-80: virtio networking broken Initial Comment: Using the Qumranet Paravirtualized Ethernet Adapter, my guest doesn't get any DHCP responses (or in fact any packets received at all) after upgrading to kvm-80. kvm-79 continues to work fine. Host CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz Host dist: Ubuntu 8.04 amd64 Guest: WinXP x86 32-bit -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2405061&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
routing vs bridging with tap
I'm playing with KVM for purposes of eventually deploying it into a hosting environment and am using tap devices for my guest networking. I've routed a single IP to the tap device of a guest and enabled proxy_arp on the tap device used for the guest and the host's physical ethernet device. Networking works fine inside of the guest in this configuration, but a side effect seems to be that when migrating this guest from one host to another, the guest holds arp cache entries which point to the old MAC address and cause issues with networking. After clearing the guest's arp table proper network behavior resumes on the new host. Unfortunately, this work around causes a loss in connectivity until the arp cache can be cleared and I won't have access to log into the guests and do this once my setup is in production. I'm using routed tap devices instead of bridging the tap devices with the physical ethernet on the host because I have it in my mind that routing is better than bridging from a security and isolation standpoint when dealing with potentially untrusted guest virtual machines. Am I causing myself unnecessary pain? Should I just bridge everything together? Any ideas? Thanks in advance, Sterling Windmill -- 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: Keyboard issues with KVM-80
On Sun, Dec 7, 2008 at 7:38 PM, walt <[EMAIL PROTECTED]> wrote: > Mark Bidewell wrote: >> >> I just tried KVM-80, am I am running into keyboard issues. The arrow >> keys to not function properly and using a CentOS5 guest the up arrow >> brings up the "Save screenshot" dialog in gnome. > > That annoying screenshot problem is caused by the evdev driver in > xorg. I fix it by deleting the evdev driver :o) I have yet to > hear anyone explain what problem evdev is supposed to solve. For > lots of people it just creates the problem you describe. > > -- > 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 > Thanks, I will check into that, however, under console mode on F10 only the arrows on the keypad 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: Keyboard issues with KVM-80
Mark Bidewell wrote: I just tried KVM-80, am I am running into keyboard issues. The arrow keys to not function properly and using a CentOS5 guest the up arrow brings up the "Save screenshot" dialog in gnome. That annoying screenshot problem is caused by the evdev driver in xorg. I fix it by deleting the evdev driver :o) I have yet to hear anyone explain what problem evdev is supposed to solve. For lots of people it just creates the problem you describe. -- 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: Problem with PCI device assignment (KVM-79, 2.6.28)
Jakob Sandgren wrote: > > Hi, > > > > I get the following (fatal) error when trying to assign a pci device > > (USB 2.0 controller) to a guest: > > create_userspace_phys_mem: Invalid argument > > assigned_dev_iomem_map: Error: create new mapping failed > > > > Assigning another (USB 1.1) device works. > > > > Can you check what lspci -v says? I suspect the size of a memory region is not a multiple of 4096. Same thing happens for me for a network and a dvb card. As far as I know, the mapping code can only map whole pages. So the code has to expand the size to the nearest multiple. Best regards, Jan C. Bernauer -- 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
Video problems with kvm-80
Just upgraded from -79 to -80. Host is Linux 2.6.24.5-smp; guests are XP0, XP3 and Linux 2.4.x. Using the kernel drivers out of the new build. Everything seems to work except for VGA updates. Whether via SDL or VNC, the screen is laggy to the point of unusabilty. If you switch to the console and back, then the screen updates OK to that moment in time, but otherwise the contents of the virtual screen are frozen mid-update (sometimes with half a popup box drawn, and with the mouse pointer invisible or in some previous position), sometimes tens of seconds in the past. This happens similarly with both cirrus VGA (that's the default, right?) and with '-vga std'. For example, at the XP logon screen, the centre of the login (GINA) prompt box appears. The border is incompletely drawn. There is no mouse pointer. If you can guess where to click (or see from the local mouse dot using VNC), or if you press [Enter], then logon proceeds OK, ending with a messed up screen with half my wallpaper visible over the blue background. and a balloon help notice which should have vanished 30 seconds before... Reverted to kvm-79, all good. Any advice? -- 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: Problem with PCI device assignment (KVM-79, 2.6.28)
Hi, just saw the kvm-80 announcement, and from the changelog, I think this might be fixed already. Best regards, Jan -- 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
Keyboard issues with KVM-80
I just tried KVM-80, am I am running into keyboard issues. The arrow keys to not function properly and using a CentOS5 guest the up arrow brings up the "Save screenshot" dialog in gnome. Are these knowm issues? Mark Bidewell -- 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-userspace: VGA/VESA framebuffer broken
Avi Kivity wrote: > Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> Jan Kiszka wrote: >>> Garbage is gone, but update does not happen automatically. I have to switch to the monitor or some other SDL console in back in order to see the latest framebuffer updates. [] > I reproduced this on opensuse 11, and applied a fix. Unfortunately > kvm-80 is broken wrt this bug. Will release kvm-81 sooner than usual. Oh, it's not just framebuffer, and not just opensuse. It also is broken on X window and windows(xp) -- see my reply to the release announcement. Is this fix available as a patchch somewhere, for me to try please? :) Thanks! /mjt -- 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
Problem with PCI device assignment (KVM-79, 2.6.28)
Hi, I get the following (fatal) error when trying to assign a pci device (USB 2.0 controller) to a guest: create_userspace_phys_mem: Invalid argument assigned_dev_iomem_map: Error: create new mapping failed Assigning another (USB 1.1) device works. Backgroud and additional information: This is on an Ubuntu Intrepid with an AMD Phenom(tm) 9350e CPU. KVM-79 has been compiled and 2.6.28 is installed from Ubuntu:s repository. I'm trying to assign my DVB-T (Nova 500) card to my guest. It's basically a PCI card with an USB controller chip (two 1.1 ports and one 2.0 port) that is connected to the actuall DVB-T chip. Since the DVB-T chip is connected to USB-2.0 and since there is no USB 2.0 (EHCI) support in KVM, I'm trying to use pci device assignment instead. I have disabled any other USB controllers/hubs in the system; [EMAIL PROTECTED]:/var/log/libvirt/qemu# lspci |grep USB 06:07.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1Controller (rev 61) 06:07.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 06:07.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) Starting kvm with; "/usr/bin/kvm -pcidevice host=06:07.1,dma=none ... args ..." works and the device shows up in the guest (some errors in guest, but it starts and the device sees an USB controller) However starting kvm with; "/usr/bin/kvm -pcidevice host=06:07.2,dma=none ... args ..." gives the following errors; create_userspace_phys_mem: Invalid argument assigned_dev_iomem_map: Error: create new mapping failed I have tried above both with and without ",dma=none". I'm confused since it seem to work with some devices, but not with others. Any suggestions? /Jakob -- Jakob Sandgren South Pole AB -- 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: [ANNOUNCE] kvm-80 release
Avi Kivity wrote: > We're continuing the merge with kvm support in upstream qemu, and this > is rocking the boat; please test carefully. Ok, this is a first "bugreport", so to say, and first time I replying to an announcement - i.e, it' the first time kvm does not work for me right out of the box... ;) Here -- attached - is an example of default-install of WinXP running under freshly-installed kvm-80. This shot was taken when I pressed Down and Right arrow keys already, so some parts of the screen actually appeared. In short: no screen updates. Not even mouse cursor - the display is constant no matter what. Just sometimes, very rare, it redraws some parts, and continues. Just like on the example screen - the hourglass is long gone, the mouse has been moved many times already (by me trying it), yet it's still here right on the center of the screen... This happens on 2.6.27 kernel from kernel.org, 32bits, on an amd athlon x2-64 CPU, with the default cirrus-logic VGA emulation. With -vga std windows does not appear at all, just a black screen. The guest (one of a few) is a cloned default winXP (russian) SP3 install, worked with several previous kvm releases. I'm trying other games now, like safe mode or reinstalling 'doze with the current kvm, but for some reason I think it will not do the trick... So here we go. Thanks! ... > - fix rendering regressions introduced by upstream qemu rendering support BTW, maybe this is it? ;) /mjt <>
Re: Problems with KVM-79
Hi, in addition to this, I just tried updating to the most recent development code (got it via git). The CentOS 5.2 VMs at least booted up fine, however, the Windows 2008 Server immediately threw a bluescreen right after asking whether to boot regularly or in safe mode (just killed of the qemu process before). Switching back to KVM-79 again, everything ran "fine" again, except for the problems explained below. So this is just to let you know that Win2008 support seems broken in the current development tree. Cheers, Chris > Hi, > > I was running KVM-76 with 2 CentOS 5.2 64bit VMs until a few days ago. > Everything was working fine. However, I needed to install a third VM running > Windows 2008 Server 64bit, which randomly kept crashing the host system with a > kernel panic, so I thought, why not upgrade to KVM-79, wanted to do that for a > while anyways. Now, Windows 2008 Server is running absolutely fine, no more > host > crashes. However, the two CentOS VMs crash on me every once in a while for no > good reason. This apparently seems to happen more often when one of the CentOS > VMs is under load, like compiling something. I had one of the VMs crash on me > like 10 times to get a PHP 5.2.7 compile thru. I tried starting up the > crashing > VM with -no-kvm, and the problem at least seemed to go away. I didn't leave it > running like this too long as the VM is in production and with -no-kvm, > everything ran terribly slow. > > Here's some infos about the system I'm using: > > Hardware: > - Intel Core2Quad Q6600 > - 8 GB RAM (checked with memtest86+ to make sure it's good) > - 2x 320 GB Seagate drives in a software RAID-1 > > Software: > - Host system: CentOS 5.2 64bit > - VMs: 2x CentOS 5.2 64bit (same kernel as host, see below), 1x Windows Server > 2008 64bit, all available updates installed > - manually compiled KVM-79 > - Host kernel version: 2.6.18-92.1.18.el5 > > qemu commands: > > VM1 (CentOS 5.2 64bit): > export DISPLAY=:1 > qemu-kvm -daemonize -localtime -no-acpi -hda /kvm/vm1.img -m 1024 -boot c -net > nic,macaddr=52:54:00:00:01:00,model=e1000 -net tap,ifname=tap0,script=no > > VM2 (Windows Server 2008 64bit): > export DISPLAY=:2 > qemu-kvm -daemonize -localtime -hda /kvm/vm2.img -m 2048 -boot c -net > nic,macaddr=52:54:00:00:01:01,model=e1000 -net tap,ifname=tap1,script=no > > VM3 (CentOS 5.2 64bit): > export DISPLAY=:3 > qemu-kvm -daemonize -localtime -hda /kvm/vm3.img -m 1024 -boot c -net > nic,macaddr=52:54:00:00:01:02,model=e1000 -net tap,ifname=tap2,script=no > > (qemu-kvm is a symlink to qemu-system-x86_64, inspired by the CentOS packages > provided by lfarkas.org. Also tried those instead of compiling manually, btw - > same problem.) > > When the crashes happen, the qemu processes are still running on the host, but > consume a lot of CPU. Checking the vnc console, there is no output whatsoever > from the VMs, just a blank, black screen that doesn't react to anything (even > tried SysRq, nothing). > > Also, what I noticed is that CentOS 5.2 spits loads of errors about kernel > modules (don't have the exact message ready now, but I could get it later on > if > needed) when booting up as soon as -smp >=2 is used. This also did not happen > with KVM-76. When I run with -smp 1 or leave that parameter out, everything > works well - except for the random crashes. > > As this did in no way happen with KVM-76, I figure there must me a bug in the > most recent version causing this issue. > > I'd appreciate any help you could provide. If there's anything else I can do, > like provide debugging output etc., please just let me know. > -- Mit freundlichen Gruessen / Best regards Chris Kuhles Geschaeftsleitung / Managing Director Aquatix IT-Services e.K. Telefon: +49 69 24750456-0 Münzgasse 6 Telefax: +49 69 24750456-1 60311 Frankfurt am Main E-Mail: [EMAIL PROTECTED] AG Frankfurt am Main, HRA 44038 Web: http://www.aquatix.de/ -- 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: [Bochs-developers] [PATCH][BIOS] Fill IPL table accordingdiscovered ATA drives
Laurent Vivier wrote:
This patch shows in boot menu only available devices.
This patch has been tested with Bochs BIOS version from the KVM source tree.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
bios/rombios.c | 54 +-
1 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 70b3584..d2a7c09 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1981,18 +1981,6 @@ init_boot_vectors()
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
count++;
- /* First HDD */
- e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
- count++;
We need this bit for the !BX_USE_ATADRV case. Please "#if !BX_USE_ATADRV ...
#endif" it
instead of removing.
-#if BX_ELTORITO_BOOT
- /* CDROM */
- e.type = IPL_TYPE_CDROM; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
- count++;
-#endif
This is ok since BX_ELTORITO_BOOT depends on BX_USE_ATADRV.
/* Remember how many devices we have */
write_word(IPL_SEG, IPL_COUNT_OFFSET, count);
/* Not tried booting anything yet */
@@ -2027,15 +2015,19 @@ Bit16u i;
if (i >= count) return 0;
type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
sizeof(Bit16u));
- if (type != IPL_TYPE_HARDDISK)
+ if (type == IPL_TYPE_HARDDISK)
+drv = 0x80;
+ else if(type == IPL_TYPE_CDROM)
Please put a space between "if" and "(".
+drv = 0xe0;
+ else
return 0;
- for (curr = 0, drv = 0; curr < i; curr++) {
+ for (curr = 0; curr < i; curr++) {
curr_type = read_word(IPL_SEG,
IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
sizeof(Bit16u));
if (type == curr_type) drv++;
}
- return 0x80 + drv;
+ return drv;
}
#if BX_ELTORITO_BOOT
@@ -2082,6 +2074,9 @@ interactive_bootkey()
memcpyb(ss, &description, (Bit16u)(e.description >> 16),
(Bit16u)(e.description & 0x), 32);
description[32] = 0;
printf(" [%S]", ss, description);
+ } else {
+ Bit16u drive = get_bootdrv(i);
+ if (drive) printf(" (0x%02x)", drive);
get_bootdrv() returns Bit8u.
}
printf("\n");
break;
@@ -2484,6 +2479,9 @@ void ata_detect( )
Bit16u ebda_seg=read_word(0x0040,0x000E);
Bit8u hdcount, cdcount, device, type;
Bit8u buffer[0x0200];
+ Bit16u ss = get_SS();
+ ipl_entry_t e;
+ Bit16u count;
#if BX_MAX_ATA_INTERFACES > 0
write_byte(ebda_seg,&EbdaData->ata.channels[0].iface,ATA_IFACE_ISA);
@@ -2750,6 +2748,16 @@ void ata_detect( )
printf(" ATA-%d Hard-Disk (%4u MBytes)\n", version,
(Bit16u)sizeinmb);
else
printf(" ATA-%d Hard-Disk (%4u GBytes)\n", version,
(Bit16u)(sizeinmb>>10));
+ /* add to IPL list */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_HARDDISK;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, &e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
break;
case ATA_TYPE_ATAPI:
printf("ata%d %s: ",channel,slave?" slave":"master");
@@ -2758,6 +2766,18 @@ void ata_detect( )
printf(" ATAPI-%d CD-Rom/DVD-Rom\n",version);
else
printf(" ATAPI-%d Device\n",version);
+ /* add to IPL list */
+#if BX_ELTORITO_BOOT
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_CDROM;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, &e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
+#endif
break;
case ATA_TYPE_UNKNOWN:
printf("ata%d %s: Unknown device\n",channel,slave?" slave":"master");
@@ -10663,6 +10683,8 @@ post_default_ints:
;;
call hard_drive_post
+ call _init_boot_vectors
+
#if BX_USE_ATADRV
;;
@@ -10682,8 +10704,6 @@ post_default_ints:
;;
#endif // BX_ELTORITO_BOOT
- call _init_boot_vectors
-
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
--
- Sebastian
--
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
Problems with KVM-79
Hi, I was running KVM-76 with 2 CentOS 5.2 64bit VMs until a few days ago. Everything was working fine. However, I needed to install a third VM running Windows 2008 Server 64bit, which randomly kept crashing the host system with a kernel panic, so I thought, why not upgrade to KVM-79, wanted to do that for a while anyways. Now, Windows 2008 Server is running absolutely fine, no more host crashes. However, the two CentOS VMs crash on me every once in a while for no good reason. This apparently seems to happen more often when one of the CentOS VMs is under load, like compiling something. I had one of the VMs crash on me like 10 times to get a PHP 5.2.7 compile thru. I tried starting up the crashing VM with -no-kvm, and the problem at least seemed to go away. I didn't leave it running like this too long as the VM is in production and with -no-kvm, everything ran terribly slow. Here's some infos about the system I'm using: Hardware: - Intel Core2Quad Q6600 - 8 GB RAM (checked with memtest86+ to make sure it's good) - 2x 320 GB Seagate drives in a software RAID-1 Software: - Host system: CentOS 5.2 64bit - VMs: 2x CentOS 5.2 64bit (same kernel as host, see below), 1x Windows Server 2008 64bit, all available updates installed - manually compiled KVM-79 - Host kernel version: 2.6.18-92.1.18.el5 qemu commands: VM1 (CentOS 5.2 64bit): export DISPLAY=:1 qemu-kvm -daemonize -localtime -no-acpi -hda /kvm/vm1.img -m 1024 -boot c -net nic,macaddr=52:54:00:00:01:00,model=e1000 -net tap,ifname=tap0,script=no VM2 (Windows Server 2008 64bit): export DISPLAY=:2 qemu-kvm -daemonize -localtime -hda /kvm/vm2.img -m 2048 -boot c -net nic,macaddr=52:54:00:00:01:01,model=e1000 -net tap,ifname=tap1,script=no VM3 (CentOS 5.2 64bit): export DISPLAY=:3 qemu-kvm -daemonize -localtime -hda /kvm/vm3.img -m 1024 -boot c -net nic,macaddr=52:54:00:00:01:02,model=e1000 -net tap,ifname=tap2,script=no (qemu-kvm is a symlink to qemu-system-x86_64, inspired by the CentOS packages provided by lfarkas.org. Also tried those instead of compiling manually, btw - same problem.) When the crashes happen, the qemu processes are still running on the host, but consume a lot of CPU. Checking the vnc console, there is no output whatsoever from the VMs, just a blank, black screen that doesn't react to anything (even tried SysRq, nothing). Also, what I noticed is that CentOS 5.2 spits loads of errors about kernel modules (don't have the exact message ready now, but I could get it later on if needed) when booting up as soon as -smp >=2 is used. This also did not happen with KVM-76. When I run with -smp 1 or leave that parameter out, everything works well - except for the random crashes. As this did in no way happen with KVM-76, I figure there must me a bug in the most recent version causing this issue. I'd appreciate any help you could provide. If there's anything else I can do, like provide debugging output etc., please just let me know. -- Mit freundlichen Gruessen / Best regards Chris Kuhles Geschaeftsleitung / Managing Director Aquatix IT-Services e.K. Telefon: +49 69 24750456-0 Münzgasse 6 Telefax: +49 69 24750456-1 60311 Frankfurt am Main E-Mail: [EMAIL PROTECTED] AG Frankfurt am Main, HRA 44038 Web: http://www.aquatix.de/ -- 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: [Bochs-developers] [PATCH][BIOS] Add BCV option rom in boot menu
Sebastian Herbszt wrote: Laurent Vivier wrote: This patch allows to select and boot from an option ROM with a Boot Connection Vector (BCV) entry. The BIOS detects the BCV option ROM and adds it to the IPL table, and then you are able to select it to boot. This patch has been tested with Bochs BIOS version from the KVM source tree and a gPXE ROM modified to be a BCV one. Any plans to convert extboot into a compatible option rom? I think the plan is to replace extboot with gPXE, and load it by default in QEMU. Since it supports BCV and BEV, we can rely on passing a boot index to choose which device to boot from. I was thinking about what to do about SCSI boot support. We could add an LSI driver to gPXE too. That seems like a bit much though. We could add a special virtio transport for gPXE and then reuse virtio-blk to boot from arbitrary devices. Regards, Anthony Liguori -- 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: [Bochs-developers] [PATCH][BIOS] Add BCV option rom in boot menu
Laurent Vivier wrote:
This patch allows to select and boot from an option ROM
with a Boot Connection Vector (BCV) entry.
The BIOS detects the BCV option ROM and adds it to the IPL table, and then
you are able to select it to boot.
This patch has been tested with Bochs BIOS version from the KVM source tree
and a gPXE ROM modified to be a BCV one.
Any plans to convert extboot into a compatible option rom?
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
bios/rombios.c | 71 ++-
1 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..70b3584 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -180,7 +180,11 @@
might as well also add
#define IPL_TYPE_RESERVED 0x00
#define IPL_TYPE_FLOPPY 0x01
#define IPL_TYPE_HARDDISK0x02
#define IPL_TYPE_CDROM 0x03
+#define IPL_TYPE_PCMCIA 0x04
+#define IPL_TYPE_USBDEVICE 0x05
+#define IPL_TYPE_NETWORK 0x06
Should this be somehow marked as embedded network? Maybe a comment.
#define IPL_TYPE_BEV 0x80
+#define IPL_TYPE_UNKNOWN 0xff
// Sanity Checks
#if BX_USE_ATADRV && BX_CPU<3
@@ -2009,6 +2013,31 @@ Bit16u i; ipl_entry_t *e;
return 1;
}
+static Bit8u
+get_bootdrv(i)
+Bit16u i;
+{
+ Bit16u count;
+ Bit16u type;
+ Bit16u curr_type;
+ Bit16u curr;
+ Bit16u drv;
+ /* Get the count of boot devices, and refuse to overrun the array */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ if (i >= count) return 0;
Add a comment that we return "floppy" on overrun?
+ type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+ if (type != IPL_TYPE_HARDDISK)
+return 0;
+ for (curr = 0, drv = 0; curr < i; curr++) {
+curr_type = read_word(IPL_SEG,
+ IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+if (type == curr_type) drv++;
+ }
+ return 0x80 + drv;
+}
+
#if BX_ELTORITO_BOOT
void
interactive_bootkey()
@@ -2047,8 +2076,15 @@ interactive_bootkey()
case IPL_TYPE_FLOPPY:
case IPL_TYPE_HARDDISK:
case IPL_TYPE_CDROM:
-printf("%s\n", drivetypes[e.type]);
-break;
+printf("%s", drivetypes[e.type]);
+if (e.description != 0)
+{
+ memcpyb(ss, &description, (Bit16u)(e.description >> 16),
(Bit16u)(e.description & 0x), 32);
+ description[32] = 0;
+ printf(" [%S]", ss, description);
+ }
+ printf("\n");
+ break;
case IPL_TYPE_BEV:
printf("%s", drivetypes[4]);
if (e.description != 0)
@@ -8045,7 +8081,7 @@ Bit16u seq_nr;
case IPL_TYPE_FLOPPY: /* FDD */
case IPL_TYPE_HARDDISK: /* HDD */
-bootdrv = (e.type == IPL_TYPE_HARDDISK) ? 0x80 : 0x00;
+bootdrv = get_bootdrv(bootdev);
bootseg = 0x07c0;
status = 0;
@@ -10245,10 +10281,11 @@ block_count_rounded:
mov bx, 0x001a ;; 0x1A is the offset into ROM header that contains...
mov ax, [bx] ;; the offset of PnP expansion header, where...
cmp ax, #0x5024 ;; we look for signature "$PnP"
- jne no_bev
+ jne no_pnp
mov ax, 2[bx]
cmp ax, #0x506e
- jne no_bev
+ jne no_pnp
+ ;; Look for the Bootstrap Entry Vector (BEV)
mov ax, 0x1a[bx] ;; 0x1A is also the offset into the expansion header of...
cmp ax, #0x ;; the Bootstrap Entry Vector, or zero if there is none.
je no_bev
@@ -10259,9 +10296,29 @@ block_count_rounded:
mov ds, bx
mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
cmp bx, #IPL_TABLE_ENTRIES
- je no_bev ;; Get out if the table is full
+ je no_pnp ;; Get out if the table is full
shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
mov 0[bx], #IPL_TYPE_BEV;; This entry is a BEV device
+ jmp add_ipl
+
+no_bev:
+ ;; Look for the Boot Connection Vector (BCV)
+ mov ax, 0x16[bx] ;; 0x16 is also the offset into the expansion header of...
"also" is wrong in this comment
+ cmp ax, #0x ;; the Boots Entry Vector, or zero if there is none.
Boot Connection Vector
+ je no_pnp
+
+ ;; Found a device that thinks it can boot the system.
+ mov di, 0x10[bx];; Pointer to the product name string or zero
if none
+ mov bx, #IPL_SEG;; Go to the segment where the IPL table lives
+ mov ds, bx
+ mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
+ cmp bx, #IPL_TABLE_ENTRIES
+ je no_pnp ;; Get out if the table is full
+ shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
+ mov 0[bx], #IPL_TYPE_HARDDISK;; This entry is a BEV device
BCV device
+
+add_ipl:
+
mov 6[bx], cx ;; Build a far pointer from the segment...
mov 4[bx], ax ;; and the offset
cmp di, #0x
@@
Re: [PATCH 1/2] kvm: use modern cpumask primitives, no cpumask_t on stack
Avi Kivity wrote:
Rusty Russell wrote:
We're getting rid on on-stack cpumasks for large NR_CPUS.
1) Use cpumask_var_t and alloc_cpumask_var (a noop normally). Fallback
code is inefficient but never happens in practice.
Wow, code duplication from Rusty. Things must be bad.
Since we're in a get_cpu() here, how about a per_cpu static cpumask
instead? I don't mind the inefficient fallback, just the duplication.
Btw, for the general case, instead of forcing everyone to duplicate, how
about:
cpumask_var_t cpus;
with_cpumask(cpus) {
... code to populate cpus
smp_call_function_some(...);
} end_with_cpumask(cpus);
Where with_cpumask() allocates cpus, and uses a mutex + static fallback
on failure.
May need a couple of variants (spinlock + GFP_NOWAIT, mutex with
sleeping allocation).
--
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 1/2] kvm: use modern cpumask primitives, no cpumask_t on stack
Rusty Russell wrote:
We're getting rid on on-stack cpumasks for large NR_CPUS.
1) Use cpumask_var_t and alloc_cpumask_var (a noop normally). Fallback
code is inefficient but never happens in practice.
2) smp_call_function_mask -> smp_call_function_many
3) cpus_clear, cpus_empty, cpu_set -> cpumask_clear, cpumask_empty,
cpumask_set_cpu.
--- linux-2.6.orig/virt/kvm/kvm_main.c
+++ linux-2.6/virt/kvm/kvm_main.c
@@ -358,11 +358,23 @@ static void ack_flush(void *_completed)
void kvm_flush_remote_tlbs(struct kvm *kvm)
{
int i, cpu, me;
- cpumask_t cpus;
+ cpumask_var_t cpus;
struct kvm_vcpu *vcpu;
me = get_cpu();
- cpus_clear(cpus);
+ if (!alloc_cpumask_var(&cpus, GFP_ATOMIC)) {
+ /* Slow path on failure. Call everyone. */
+ for (i = 0; i < KVM_MAX_VCPUS; ++i) {
+ vcpu = kvm->vcpus[i];
+ if (vcpu)
+ set_bit(KVM_REQ_TLB_FLUSH, &vcpu->requests);
+ }
+ ++kvm->stat.remote_tlb_flush;
+ smp_call_function_many(cpu_online_mask, ack_flush, NULL, 1);
+ put_cpu();
+ return;
+ }
+
Wow, code duplication from Rusty. Things must be bad.
Since we're in a get_cpu() here, how about a per_cpu static cpumask
instead? I don't mind the inefficient fallback, just the duplication.
--
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] kvm: use cpumask_var_t for cpus_hardware_enabled
Rusty Russell wrote: This changes cpus_hardware_enabled from a cpumask_t to a cpumask_var_t: equivalent for CONFIG_CPUMASKS_OFFSTACK=n, otherwise dynamically allocated. -static cpumask_t cpus_hardware_enabled; +static cpumask_var_t cpus_hardware_enabled This isn't on stack, so it isn't buying us anything. Is the plan to drop cpumask_t? If so, we're penalizing non-stack users by forcing them to go through another pointer (and cacheline). -- 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: kvm-userspace: VGA/VESA framebuffer broken
Jan Kiszka wrote: Avi Kivity wrote: Jan Kiszka wrote: Garbage is gone, but update does not happen automatically. I have to switch to the monitor or some other SDL console in back in order to see the latest framebuffer updates. That was indeed a symptom during the brokenness. Which guest are you running? Various home-brewed or openSuse kernels from 2.6.23 to 27. I reproduced this on opensuse 11, and applied a fix. Unfortunately kvm-80 is broken wrt this bug. Will release kvm-81 sooner than usual. -- 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] virtio: make PCI devices take a virtio_pci module ref
Rusty Russell wrote: >> Fix the virtio bus instead. > > Incoherent? CHECK Sorry, I don't undesratnd here. Incoherent with what? > Rude to bug reporter? CHECK Maybe it's my english. I apologize all, who understood my replies that way, sorry for that, it was not intentional. > Unhelpful? CHECK I don't know, I expect people to ask for concrete implementation details, if they don't know. Ok, pointing to the relevant documentation next time would be better, I agree. -- 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
[ANNOUNCE] kvm-80 release
We're continuing the merge with kvm support in upstream qemu, and this is rocking the boat; please test carefully. Important note: unlike most kvm releases, userspace in this release is required the modules from kvm-80 (or above), and will not work with older versions or with the modules provided by the upstream kernel. This will be corrected in kvm-81. Changes from kvm-79: - merge qemu-svn - automatic port allocation for vnc and similar - improved cdrom media change handling - improved debugging support - more scsi improvements - e1000 vlan offload - up to 256 vcpus for ia64 (Jes Sorensen) - only request io port permission if device assignment is enabled (Jes Sorensen) - fix in-kernel ioapic reset (Jan Kiszka) - fixes guest reboot failures - fix balloon for systems with page size different from 4K (Hollis Blanchard) - fix bios memory reporting with >32G guests (Bill Rieske) - drop inclusion of compiler.h in external modules (Xiantao Zhang) - use vcpu pointers instead of vcpu numbers (Jes Sorensen) - goodbye bool (Jes Sorensen) - stop using separate structure for cpu state; use qemu's instead (Jes Sorensen) - apic testsuite - fix -no-kvm apic with smp (Jan Kiszka) - clean up userspace nmi injection (Jan Kiszka) - adjust external module for 2.6.28 hosts (Mark McLoughlin) - much improved large mtu/gso support for virtio-net (Mark McLoughlin) - simplify x86 emulator stack pop operations - clean up device assignment code (Mark McLoughlin) - fix extboot returning error incorrectly (Glauber Costa) - constrain device assignment mmio to page alignment (Han Weidong) - ppc speedups (Hollis Blanchard) - fix s390 problem state handling (Christian Borntraeger) - fix interrupt loss when injecting an nmi - fixes Linux guests with nmi watchdog hanging - fix ia64 build (Xiantao Zhang) - fix emergency reboot and kdump on host while running VMs (Eduardo Habkost) - fix syncing of self-referencing ptes (Marcelo Tosatti) - add printk() for ia64 vmm (Xiantao Zhang) - add crashed vm handler for ia64 (Xiantao Zhang) - use correct calling convention into ia64 PAL code (Xiantao Zhang) - request interrupt window after injecting an interrupt if another is pending - plug ppc memory leak when destroying a vm - sign kvmclock as a paravirt operation (Glauber Costa) - MSI support for device assigment (Sheng Yang) - fix shadow pagetables leak (Marcelo Tosatti) - fixes an oops - optimize setting new pte while syncing a page (Marcelo Tosatti) - reduce code duplication in x86 emulator - fix s390 refcounting; allow module unload (Christian Borntraeger) - fix s390 memory leak (Christian Borntraeger) - prevent tracing calls into unloaded module (Wu Fengguang) - fix sparse warnings (Hannes Eder) - clean up irq ack notifiers (Mark McLoughlin) - powerpc large page support (Hollis Blanchard) - faster powerpc shadow tlb handling (Hollis Blanchard) - reduce powerpc guest tlb miss rate on context switches (Hollis Blanchard) - powerpc exit timing stats (Hollis Blanchard) - fix -no-kvm-irqchip not working with smp (Jan Kiszka) - fix rendering regressions introduced by upstream qemu rendering support -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: Fix -no-kvm-irqchip
Jan Kiszka wrote: Commit fc94d163d1e3424199166cf50449e03447400579 broke -no-kvm-irqchip. This fixes the issue by restoring the logic of kvm_update_interrupt_request /wrt IRQ injection from the IO thread. Applied, thanks. [However, I did not yet get the need for all the additional tests in that function.] Neither does the comment in that function... -- 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 3/5] KVM: VMX: Ensure interruptibility when single-stepping
Jan Kiszka wrote:
When single-stepping, we have to ensure that the INT1 can make it
through even if the guest itself is uninterruptible due to MOV SS or
STI. VMENTRY will fail otherwise.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3a422dc..8e83102 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1010,6 +1010,7 @@ static void vmx_cache_reg(struct kvm_vcpu *vcpu, enum
kvm_reg reg)
static int set_guest_debug(struct kvm_vcpu *vcpu, struct kvm_guest_debug *dbg)
{
int old_debug = vcpu->guest_debug;
+ u32 interruptibility;
unsigned long flags;
vcpu->guest_debug = dbg->control;
@@ -1017,9 +1018,14 @@ static int set_guest_debug(struct kvm_vcpu *vcpu, struct
kvm_guest_debug *dbg)
vcpu->guest_debug = 0;
flags = vmcs_readl(GUEST_RFLAGS);
- if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
+ if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
flags |= X86_EFLAGS_TF | X86_EFLAGS_RF;
- else if (old_debug & KVM_GUESTDBG_SINGLESTEP)
+ /* We must be interruptible when single-stepping */
+ interruptibility = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ if (interruptibility & 3)
+ vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
+interruptibility & ~3);
Could just write unconditionally - it's not like the write has any
effect on speed. vmcs_clear_bits() will do it cleanly.
But I'm worried about correctness. Suppose we're singlestepping a sti;
hlt sequence. While we'll clear interruptibility, probably receive the
debug trap (since that's a high priority exception), but then inject the
interrupt before the hlt, hanging the guest. So we probably need to
restore interruptibility on exit.
This looks like a good candidate for a test case.
--
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/5] KVM: New guest debug interface
Jan Kiszka wrote:
This rips out the support for KVM_DEBUG_GUEST and introduces a new IOCTL
instead: KVM_SET_GUEST_DEBUG. The IOCTL payload consists of a generic
part, controlling the "main switch" and the single-step feature. The
arch specific part adds an x86 interface for intercepting both types of
debug exceptions separately and re-injecting them when the host was not
interested. Moveover, the foundation for guest debugging via debug
registers is layed.
Have you tested compile-time compatibility with older userspace?
Note that both SVM and VTX are supported, but only the latter was tested
yet. Based on the experience with all those VTX corner case, I would be
fairly surprised if SVM will work out of the box.
I'd like svm to work before applying.
@@ -439,7 +437,8 @@ struct kvm_trace_rec {
#define KVM_SET_SREGS _IOW(KVMIO, 0x84, struct kvm_sregs)
#define KVM_TRANSLATE _IOWR(KVMIO, 0x85, struct kvm_translation)
#define KVM_INTERRUPT _IOW(KVMIO, 0x86, struct kvm_interrupt)
-#define KVM_DEBUG_GUEST _IOW(KVMIO, 0x87, struct kvm_debug_guest)
+/* KVM_DEBUG_GUEST is no longer supported, use KVM_SET_GUEST_DEBUG instead */
+#define KVM_DEBUG_GUEST __KVM_DEPRECATED_DEBUG_GUEST
#define KVM_GET_MSRS _IOWR(KVMIO, 0x88, struct kvm_msrs)
#define KVM_SET_MSRS _IOW(KVMIO, 0x89, struct kvm_msrs)
#define KVM_SET_CPUID _IOW(KVMIO, 0x8a, struct kvm_cpuid)
@@ -468,6 +467,26 @@ struct kvm_trace_rec {
#define KVM_SET_MP_STATE _IOW(KVMIO, 0x99, struct kvm_mp_state)
/* Available with KVM_CAP_NMI */
#define KVM_NMI _IO(KVMIO, 0x9a)
+/* Available with KVM_CAP_SET_GUEST_DEBUG */
+#define KVM_SET_GUEST_DEBUG _IOW(KVMIO, 0x9a, struct kvm_guest_debug)
+
0x9b...
--
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] kvm_get_tsc_khz: return khz, not lpj
Eduardo Habkost wrote: kvm_get_tsc_khz() currently returns the previously-calculated preset_lpj value, but it is in loops-per-jiffy, not kHz. The current code works correctly only when HZ=1000. 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: [PATCH] virtio: make PCI devices take a virtio_pci module ref
On Friday 05 December 2008 23:47:06 Jiri Slaby wrote: > Michael Tokarev napsal(a): > > Jiri Slaby wrote: > >> On 12/04/2008 01:44 PM, Mark McLoughlin wrote: > >>> Nothing takes a ref on virtio_pci, so even if you have > >>> devices in use, rmmod will attempt to unload the module. > >> It unbinds the device properly as any other driver. So what's the problem > >> here? > > > > Here's what we get when rmmod'ing (a zero-refcounted but > > in use) virtio_pci (I did it by a chance, cut-n-pasted > > the wrong line): > > > > WARNING: at drivers/base/core.c:122 device_release+0x5f/0x70() > > Device 'virtio1' does not have a release() function, it is broken and must > > be fixed. > > Modules linked in: ext3 jbd mbcache acpiphp dock pci_hotplug virtio_net > > virtio_blk virtio_pci(-) virtio_ring virtio > > > > Pid: 361, comm: rmmod Tainted: G S2.6.27-i686smp #2.6.27.7 > > [] warn_slowpath+0x6f/0xa0 > > [] prepare_set+0x30/0x80 > > [] __wake_up+0x3e/0x60 > > [] release_sysfs_dirent+0x45/0xb0 > > ... > > So why don't you fix the root cause and add such a crap into the probe > function (not even counting probe can fail later)? > > Fix the virtio bus instead. Incoherent? CHECK Rude to bug reporter? CHECK Unhelpful? CHECK Wow, you must be a *great* kernel maintainer! Thanks for making us all so very, very proud. Rusty. -- 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] virtio: make PCI devices take a virtio_pci module ref
On Saturday 06 December 2008 01:37:06 Mark McLoughlin wrote: > Another example of a lack of an explicit dependency causing problems is > Fedora's mkinitrd having this hack: > > if echo $PWD | grep -q /virtio-pci/ ; then > findmodule virtio_pci > fi > > which basically says "if this is a virtio device, don't forget to > include virtio_pci in the initrd too!". Now, mkinitrd is full of hacks, > but this is a particularly unusual one. Um, I don't know what this does, sorry. I have no idea how Fedora chooses what to put in an initrd; I can't think of a sensible way of deciding what goes in and what doesn't other than lists and heuristics. But there really is no explicit dependency between virtio modules and virtio_pci. There just is for kvm/x86 at the moment, since that is how they use virtio. Running over another bus is certainly possible, though may never happen for x86 (happens today for s390). Cheers, Rusty. -- 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
