Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2008-05-06 13:21:25
|
Bugs item #1958725, was opened at 2008-05-06 16:21 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=1958725&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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: openSUSE 11.0 became broken with newer KVM Initial Comment: Host OS: Fedora7/x64, kernel 2.6.21 Guest OS: openSUSE 11.0 BETA2, 32-bit x86 DVD ISO, kernel 2.6.25 CPU: Intel Core 2 KVM: KVM-67 (bug also valid for KVM-68) KVM-67 broke openSUSE 11.0 on newer KVMs-67/68 on intel. command: ./qemu-kvm -cdrom openSUSE-11.0-BETA2-32-bit.iso -m 512 -hda myharddisk.qcow2 -boot d Symptoms: Red error message is displayed in the guest monitor, during setup stage2 (Yast) load. I have bisected it. qemu-merge for KVM-67 userspace is responsible for this bug, commit: c33833a3f98b1bb9d8208b0ed115009bc20e6e87 Works fully on KVM-66. On KVM-67/68 it works only with "-no-kvm" parameter. FAILS with default parameters, fails with -no-kvm-acpi, -no-kvm-pit, -no-kvm-irqchip, and fails when guest is loaded with normal or FAILSAFE kernel boot parameters. That is: fails in all cases. -Alexey "Technologov", 6.May.2008. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958725&group_id=180599 |
|
From: Guillaume T. <gui...@ex...> - 2008-05-06 13:21:07
|
On Tue, 06 May 2008 06:13:18 -0700 "SourceForge.net" <no...@so...> wrote: > When I use the commit bae043c (kvm-userspace) I can start the liveCD > but the next commit c33833a produces a kernel panic. I see the screen > with different choice of installation but when I choose to install > linux I get a kernel panic (see file attach). I insert the report of the kernel panic: --- [guill@enterprise][~/local/kvm-userspace.git/bin]$ ./qemu-system-x86_64 -cdrom /images_iso/ubuntu-8.04-desktop-i386.iso -boot d -m 256 -serial stdio kvm_set_lapic: Bad file descriptor [ 0.000000] Linux version 2.6.24-16-generic (buildd@palmer) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Thu Apr 10 13:23:42 UTC 2008 (Ubuntu 2.6.24-16.30-generic) [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000000fff0000 (usable) [ 0.000000] BIOS-e820: 000000000fff0000 - 0000000010000000 (ACPI data) [ 0.000000] BIOS-e820: 00000000fffbd000 - 0000000100000000 (reserved) [ 0.000000] 0MB HIGHMEM available. [ 0.000000] 255MB LOWMEM available. [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0 -> 4096 [ 0.000000] Normal 4096 -> 65520 [ 0.000000] HighMem 65520 -> 65520 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[1] active PFN ranges [ 0.000000] 0: 0 -> 65520 [ 0.000000] DMI 2.4 present. [ 0.000000] ACPI: RSDP signature @ 0xC00FB450 checksum 0 [ 0.000000] ACPI: RSDP 000FB450, 0014 (r0 QEMU ) [ 0.000000] ACPI: RSDT 0FFF0000, 002C (r1 QEMU QEMURSDT 1 QEMU 1) [ 0.000000] ACPI: FACP 0FFF002C, 0074 (r1 QEMU QEMUFACP 1 QEMU 1) [ 0.000000] ACPI: DSDT 0FFF0100, 2464 (r1 BXPC BXDSDT 1 INTL 20061109) [ 0.000000] ACPI: FACS 0FFF00C0, 0040 [ 0.000000] ACPI: APIC 0FFF2568, 00E0 (r1 QEMU QEMUAPIC 1 QEMU 1) [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] Processor #0 6:2 APIC version 20 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] Allocating PCI resources starting at 20000000 (gap: 10000000:effbd000) [ 0.000000] swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000 [ 0.000000] swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000e8000 [ 0.000000] swsusp: Registered nosave memory region: 00000000000e8000 - 0000000000100000 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65009 [ 0.000000] Kernel command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz console=ttyS0 [ 0.000000] Enabling fast FPU save and restore... done. [ 0.000000] Enabling unmasked SIMD FPU exception support... done. [ 0.000000] Initializing CPU#0 [ 0.000000] PID hash table entries: 1024 (order: 10, 4096 bytes) [ 0.000000] Detected 3002.716 MHz processor. [ 18.835013] Console: colour VGA+ 80x25 [ 18.835162] console [ttyS0] enabled [ 18.977947] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 18.980655] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 18.989794] Memory: 247460k/262080k available (2157k kernel code, 14020k reserved, 998k data, 364k init, 0k highmem) [ 18.993372] virtual kernel memory layout: [ 18.993373] fixmap : 0xfff4b000 - 0xfffff000 ( 720 kB) [ 18.993375] pkmap : 0xff800000 - 0xffc00000 (4096 kB) [ 18.993376] vmalloc : 0xd0800000 - 0xff7fe000 ( 751 MB) [ 18.993377] lowmem : 0xc0000000 - 0xcfff0000 ( 255 MB) [ 18.993378] .init : 0xc041b000 - 0xc0476000 ( 364 kB) [ 18.993379] .data : 0xc031b5a4 - 0xc0414dc4 ( 998 kB) [ 18.993380] .text : 0xc0100000 - 0xc031b5a4 (2157 kB) [ 19.007814] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 19.011055] SLUB: Genslabs=11, HWalign=64, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 [ 19.094127] Calibrating delay using timer specific routine.. 6036.24 BogoMIPS (lpj=12072488) [ 19.097168] Security Framework initialized [ 19.098615] SELinux: Disabled at boot. [ 19.099955] AppArmor: AppArmor initialized [ 19.101367] Failure registering capabilities with primary security module. [ 19.103653] Mount-cache hash table entries: 512 [ 19.105787] CPU: L1 I cache: 32K, L1 D cache: 32K [ 19.107476] CPU: L2 cache: 2048K [ 19.108563] Compat vDSO mapped to ffffe000. [ 19.110082] Checking 'hlt' instruction... OK. [ 19.133380] SMP alternatives: switching to UP code [ 19.158537] Freeing SMP alternatives: 11k freed [ 19.160222] invalid opcode: 0000 [#1] SMP [ 19.161756] Modules linked in: [ 19.162869] [ 19.163417] Pid: 0, comm: swapper Not tainted (2.6.24-16-generic #1) [ 19.165565] EIP: 0060:[<c01a1789>] EFLAGS: 00010282 CPU: 0 [ 19.167500] EIP is at new_inode+0x9/0x90 [ 19.168858] EAX: c03f0aa4 EBX: cf000150 ECX: 00000000 EDX: 000041ed [ 19.170935] ESI: cf407200 EDI: 00000000 EBP: cf403800 ESP: c0417e88 [ 19.173162] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 19.174901] Process swapper (pid: 0, ti=c0416000 task=c03e43a0 task.ti=c0416000) [ 19.177425] Stack: cf000150 000041ed c01d567b cf000150 cf0012a8 000041ed cf403800 c01d580a [ 19.180644] cf000150 cf0012a8 cf000150 c01d5895 00000000 c0326d00 c0195979 000001ed [ 19.183855] 00000001 000001ed cf000150 cf420000 cf0012a8 c0417ee8 c0197aff 000041ed [ 19.186997] Call Trace: [ 19.187956] [<c01d567b>] ramfs_get_inode+0x1b/0x120 [ 19.189683] [<c01d580a>] ramfs_mknod+0x1a/0x80 [ 19.191189] [<c01d5895>] ramfs_mkdir+0x15/0x30 [ 19.192757] [<c0195979>] vfs_mkdir+0xc9/0x150 [ 19.194366] [<c0197aff>] sys_mkdirat+0x9f/0xe0 [ 19.195915] [<c0197b5f>] sys_mkdir+0x1f/0x30 [ 19.197399] [<c0420fda>] do_name+0x1da/0x1e0 [ 19.198867] [<c041ec3c>] write_buffer+0x1c/0x30 [ 19.200473] [<c041ecde>] flush_window+0x7e/0xd0 [ 19.202125] [<c0420b64>] unpack_to_rootfs+0x714/0x950 [ 19.204181] [<c0420dba>] early_populate_rootfs+0x1a/0x60 [ 19.206151] [<c041ba3f>] start_kernel+0x2ff/0x3a0 [ 19.207743] [<c041b130>] unknown_bootoption+0x0/0x1e0 [ 19.209505] ======================= [ 19.210903] Code: 0a 3f c0 8d 44 24 08 e8 06 fc ff ff b8 bc 0a 3f c0 e8 4c 4d 17 00 8b 04 24 83 c4 10 5b 5e 5f 5d c3 90 56 89 c6 53 b8 a4 0a 3f c0 <0f> 0d 08 90 89 f0 e8 5c f3 ff ff 85 c0 89 c3 74 66 b8 a4 0a 3f [ 19.219768] EIP: [<c01a1789>] new_inode+0x9/0x90 SS:ESP 0068:c0417e88 [ 19.222826] ---[ end trace ca143223eefdc828 ]--- [ 19.224481] Kernel panic - not syncing: Attempted to kill the idle task! [ |
|
From: SourceForge.net <no...@so...> - 2008-05-06 13:13:28
|
Bugs item #1958715, was opened at 2008-05-06 15:13 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=1958715&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: gth (gthouvenin) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-userspace failed to start linux kernel (kernel panic) Initial Comment: CPU: Intel Xeon (eight cpu) KVM: kvm-68-2049-g6307419 Host kernel arch: x86_64 Guest: Ubuntu-8.04-desktop-i386 livecd QEMU Command: qemu-system-x86_64 -cdrom /images_iso/ubuntu-8.04-desktop-i386.iso -boot d -m 256 KVM-USERSPACE: kvm-66-147-gc33833a The problem doesn't go away if I'm using the -no-kvm-irqchip or -no-kvm-pit switch. When I use the commit bae043c (kvm-userspace) I can start the liveCD but the next commit c33833a produces a kernel panic. I see the screen with different choice of installation but when I choose to install linux I get a kernel panic (see file attach). It also happens with an old fedora that is installed on a qcow2 file. Regards, Guillaume ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958715&group_id=180599 |
|
From: Avi K. <av...@qu...> - 2008-05-06 11:28:29
|
Chris Lalancette wrote: > Attached is a patch that fixes a guest crash when booting older Linux kernels. > The problem stems from the fact that we are currently emulating > MSR_K7_EVNTSEL[0-3], but not emulating MSR_K7_PERFCTR[0-3]. Because of this, > setup_k7_watchdog() in the Linux kernel receives a GPF when it attempts to write > into MSR_K7_PERFCTR, which causes an OOPs. > > The patch fixes it by just "fake" emulating the appropriate MSRs, throwing away > the data in the process. This causes the NMI watchdog to not actually work, but > it's not such a big deal in a virtualized environment. > > When we get a write to one of these counters, we printk_ratelimit() a warning. > I decided to print it out for all writes, even if the data is 0; it doesn't seem > to make sense to me to special case when data == 0. > > Tested by myself on a RHEL-4 guest, and Joerg Roedel on a Windows XP 64-bit guest. > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 11:23:31
|
Yunfeng Zhao wrote: > Three New Issues: > ================================================ > 1. "Unknown symbol in module" while loading kvm.ko on PAE host > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_id=180599 > 2. Fail to save restore and live migrate on 32e platform > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&group_id=180599 > 3. fails to build KVM modules against 2.6.26 kernel > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958519&group_id=180599 > Fixed and pushed all three. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 10:47:35
|
Carlo Marcelo Arenas Belon wrote: > apparently harmless and unique > > Sloppy me. Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 10:46:41
|
Ryota OZAKI wrote: > Hi all, > > >> Initial Comment: >> Building KVM modules against 2.6.24 kernel is ok. >> But building against 2.6.26 kernel will fail. >> > > I got the same problem, but the following Andrea's patch helped me. > > Hope this helps, > Yes, while I think it's a Kbuild problem, too many people are hitting it, so I applied the patch. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 10:36:56
|
Kay, Allen M wrote: > Still todo: move vt.d to kvm-intel.ko module. > Not sure it's the right thing to do. If we get the iommus abstracted properly, we can rename vtd.c to dma.c and move it to virt/kvm/. The code is certainly a lot more about managing memory than anything vmx specific. It's hardly x86 specific, even. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 10:34:33
|
Kay, Allen M wrote:
> +
> +#include <linux/list.h>
> +#include <linux/kvm_host.h>
> +#include <linux/pci.h>
> +#include <linux/dmar.h>
> +#include <linux/intel-iommu.h>
> +
> +//#define DEBUG
> +
> +#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
>
The name "domain" is too generic; please use dma_domain or io_domain or
something similar.
> +static int kvm_iommu_map_memslots(struct kvm *kvm)
> +{
> + int i, status;
> + for (i = 0; i < kvm->nmemslots; i++) {
> + status = kvm_iommu_map_pages(kvm,
> kvm->memslots[i].base_gfn,
> + kvm->memslots[i].npages);
> + if (status)
> + return status;
>
Need to undo in case of partial completion.
> diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
> index 5f93b78..6202ed1 100644
> --- a/include/asm-x86/kvm_para.h
> +++ b/include/asm-x86/kvm_para.h
> @@ -170,5 +170,6 @@ struct kvm_pci_pt_info {
> struct kvm_pci_passthrough_dev {
> struct kvm_pci_pt_info guest;
> struct kvm_pci_pt_info host;
> + struct pci_dev *pdev; /* kernel device pointer for host dev
> */
>
This should be stored somewhere private (not sure, but I think
kvm_pci_passthrough_dev is a public interface).
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
|
|
From: Avi K. <av...@qu...> - 2008-05-06 10:27:58
|
Kay, Allen M wrote: > Following three patches contains vt-d support for pci passthrough. It > contains diff's base on Amit's 4/22 passthrough tree. > > The hardware environment used for this work is an Intel Weybridge system > (Q35). The passthrough device is an E1000 NIC. I'm still using irqhook > mechanism for interrupt injection as I had problem with irqchip > machanism. Following is the command line I used to start the guest. > > /usr/local/bin/qemu-system-x86_64 -boot c -hda /etc/xen/fc5_32.img -m > 256 -net none -pcidevice e1000/01:00.0-16 -no-kvm-irqchip > > Remaining tasks include: > > 1) Generated vtd.o with kvm-intel.ko instead of kvm.ko. > 2) Make iommu hooks in generic code to be non-Intel specific > Eventually we will want to make it even non-x86 specific; ia64 will probably be able to share, and maybe ppc someday. That needn't be done at once, though. Your mail client mangles the patches, please attach or use git send-email. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 10:14:35
|
Alexander Graf wrote: >> Marcelo Tosatti wrote: >>> Add three PCI bridges to support 128 slots. >>> >>> Changes since v1: >>> - Remove I/O address range "support" (so standard PCI I/O space is >>> used). >>> - Verify that there's no special quirks for 82801 PCI bridge. >>> - Introduce separate flat IRQ mapping function for non-SPARC targets. >>> >>> >> >> I've cooled off on the 128 slot stuff, mainly because most real hosts >> don't have them. An unusual configuration will likely lead to problems >> as most guest OSes and workloads will not have been tested thoroughly >> with them. > > This is more of a "let's do this conditionally" than a "let's not do > it" reason imho. Yes. More precisely, let's not do it until we're sure it works and performs. I don't think a queue-per-disk approach will perform well, since the queue will always be very short and will not be able to amortize exit costs and ring management overhead very well. >> - it requires a large number of interrupts, which are difficult to >> provide, and which it is hard to ensure all OSes support. MSI is >> relatively new. > > We could just as well extend the device layout to have every device be > attached to one virtual IOAPIC pin, so we'd have like 128 / 4 = 32 > IOAPICs in the system and one interrupt for each device. That's problematic for these reasons: - how many OSes work well with 32 IOAPICs? - at one point, you run out of interrupt vectors (~ 220 per cpu if the OS can allocate per-cpu vectors; otherwise just ~220) - you will have many interrupts fired, each for a single device with a few requests, reducing performance >> - is only a few interrupts are available, then each interrupt requires >> scanning a large number of queues > > This case should be rare, basically only existent with OSs that don't > support APIC properly. > Hopefully. >> The alternative approach of having the virtio block device control up to >> 16 disks allows having those 80 disks with just 5 slots (and 5 >> interrupts). This is similar to the way traditional SCSI controllers >> behave, and so should not surprise the guest OS. > > The one thing I'm actually really missing here is use cases. What are > we doing this for? And further along the line, are there other > approaches to the problems for which this was supposed to be a > solution? Maybe someone can raise a case where it's not virtblk / > virtnet. The requirement for lots of storage is a given. There are two ways of doing that, paying a lot of money to EMC or NetApp for a storage controller, or connecting lots of disks directly and doing the storage controller on the OS (what EMC and NetApp do anyway, inside their boxes). zfs is a good example of a use case, and I'd guess databases could use this too if they were able to supply the redundancy. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-05-06 10:01:18
|
Anthony Liguori wrote: > Avi Kivity wrote: >> Marcelo Tosatti wrote: >> >>> Add three PCI bridges to support 128 slots. >>> >>> Changes since v1: >>> - Remove I/O address range "support" (so standard PCI I/O space is >>> used). >>> - Verify that there's no special quirks for 82801 PCI bridge. >>> - Introduce separate flat IRQ mapping function for non-SPARC targets. >>> >>> >> >> I've cooled off on the 128 slot stuff, mainly because most real hosts >> don't have them. An unusual configuration will likely lead to >> problems as most guest OSes and workloads will not have been tested >> thoroughly with them. >> >> - it requires a large number of interrupts, which are difficult to >> provide, and which it is hard to ensure all OSes support. MSI is >> relatively new. >> - is only a few interrupts are available, then each interrupt >> requires scanning a large number of queues >> >> If we are to do this, then we need better tests than "80 disks show up". >> >> The alternative approach of having the virtio block device control up >> to 16 disks allows having those 80 disks with just 5 slots (and 5 >> interrupts). This is similar to the way traditional SCSI controllers >> behave, and so should not surprise the guest OS. >> > > If you have a single virtio-blk device that shows up as 8 functions, > we could achieve the same thing. We can cheat with the interrupt > handlers to avoid cache line bouncing too. You can't cheat on all guests, and even on Linux, it's better to keep on doing what real hardware does than go off on a tangent than no one else uses. You'll have to cheat on ->kick(), too. Virtio needs one exit per O(queue depth). With one spindle per ring, it doesn't make sense to have a queue depth > 4 (or latency goes to hell), so you have many exits. > Plus, we can use PCI hotplug so we don't have to reinvent a new > hotplug mechanism. You can plug disks into a Fibre Channel mesh, so presumably that works on real hardware somehow. > > I'm inclined to think that ring sharing isn't as useful as it seems as > long as we don't have indirect scatter gather lists. I agree, but I think that indirect sg is very important for storage: - a long sg list is cheap from the disk's point of view (the seeks are what's expensive) - it is important to keep the queue depth meaningful and small (O(spindles * 3)), as it drastically affects latency -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Ryota O. <oza...@gm...> - 2008-05-06 09:49:36
|
Hi all,
> Initial Comment:
> Building KVM modules against 2.6.24 kernel is ok.
> But building against 2.6.26 kernel will fail.
I got the same problem, but the following Andrea's patch helped me.
Hope this helps,
ozaki-r
---------- Forwarded message ----------
From: Andrea Arcangeli <an...@qu...>
Date: 2008/4/26
Subject: [kvm-devel] fix external module compile
To: kvm...@li...
Cc: Avi Kivity <av...@qu...>
Hello,
after updating kvm-userland.git, kvm.git and linux-2.6-hg, and after
make distclean and rebuild with slightly reduced .config, I can't
compile the external module anymore. Looking into it with V=1, $(src)
defines to "" and including /external-module-compat.h clearly fails. I
fixed it like below, because it seems more consistent to enforce the
ordering of the "special" includes in the same place, notably
$(src)/include is already included as $LINUX at point 1 of the
comment, so this looks a cleanup of superflous line in Kconfig besides
fixing my compile by moving the external-module-compat in the same
place with the other includes where `pwd` works instead of $(src) that
doesn't work anymore for whatever reason.
Signed-off-by: Andrea Arcangeli <an...@qu...>
diff --git a/kernel/Kbuild b/kernel/Kbuild
index cabfc75..d9245eb 100644
--- a/kernel/Kbuild
+++ b/kernel/Kbuild
@@ -1,4 +1,3 @@
-EXTRA_CFLAGS := -I$(src)/include -include $(src)/external-module-compat.h
obj-m := kvm.o kvm-intel.o kvm-amd.o
kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o anon_inodes.o irq.o i8259.o \
lapic.o ioapic.o preempt.o i8254.o external-module-compat.o
diff --git a/kernel/Makefile b/kernel/Makefile
index 78ff923..e3fccbe 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -27,7 +27,8 @@ all::
# include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
$(MAKE) -C $(KERNELDIR) M=`pwd` \
LINUXINCLUDE="-I`pwd`/include -Iinclude -I`pwd`/include-compat \
- -include include/linux/autoconf.h" \
+ -include include/linux/autoconf.h \
+ -include `pwd`/external-module-compat.h"
"$$@"
sync: header-sync source-sync
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
kvm-devel mailing list
kvm...@li...
https://lists.sourceforge.net/lists/listinfo/kvm-devel
2008/5/6 SourceForge.net <no...@so...>:
> Bugs item #1958519, was opened at 2008-05-06 16:05
> 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=1958519&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: yunfeng (yunfeng)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: fails to build KVM modules against 2.6.26 kernel
>
> Initial Comment:
> Building KVM modules against 2.6.24 kernel is ok.
> But building against 2.6.26 kernel will fail.
>
> make -j20 -C /lib/modules/2.6.26-rc1-02049-g6307419/build M=`pwd` \
> LINUXINCLUDE="-I`pwd`/include -Iinclude -I`pwd`/include-compat \
> -include include/linux/autoconf.h" \
> "$@"
> make[1]: Entering directory `/root/kvm'
> Building modules, stage 2.
> MODPOST 3 modules
> WARNING: "kvm_div64_u64" [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.ko] undefined!
> CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-amd.mod.o
> CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-intel.mod.o
> CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.mod.o
> In file included from <command line>:1:
> ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory
> In file included from <command line>:1:
> ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory
> In file included from <command line>:1:
> ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory
> make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-intel.mod.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-amd.mod.o] Error 1
> make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.mod.o] Error 1
> make[1]: *** [modules] Error 2
> make[1]: Leaving directory `/root/kvm'
> make: *** [all] Error 2
>
>
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958519&group_id=180599
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> kvm-devel mailing list
> kvm...@li...
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
|
|
From: Carlo M. A. B. <ca...@sa...> - 2008-05-06 08:39:17
|
apparently harmless and unique Signed-off-by: Carlo Marcelo Arenas Belon <ca...@sa...> --- qemu/Makefile.target | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/qemu/Makefile.target b/qemu/Makefile.target index cc66651..bb4b9a3 100644 --- a/qemu/Makefile.target +++ b/qemu/Makefile.target @@ -190,7 +190,6 @@ all: $(PROGS) ######################################################### # cpu emulator library -<<<<<<< HEAD:qemu/Makefile.target LIBOBJS=exec.o kqemu.o cpu-exec.o host-utils.o ifeq ($(NO_CPU_EMULATION), 1) -- 1.5.3.7 |
|
From: Yunfeng Z. <yun...@in...> - 2008-05-06 08:11:18
|
Hi All, This is today's KVM test result against kvm.git 630741928b4a7eeff27e134d7ba7bc2fc2c764c5 and kvm-userspace.git 77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3. There's one new issue blocked nightly test on ia32-pae platform (issue#1958464). Three New Issues: ================================================ 1. "Unknown symbol in module" while loading kvm.ko on PAE host https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_id=180599 2. Fail to save restore and live migrate on 32e platform https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&group_id=180599 3. fails to build KVM modules against 2.6.26 kernel https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958519&group_id=180599 One Old Issues: ================================================ 4. Cannot boot guests with hugetlbfs https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599 Test environment ================================================ Platform Woodcrest CPU 4 Memory size 8G' Details ================================================ IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallel PASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests FAIL 13. save/restore 32-bit linux guests FAIL 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP windows 2008 with ACPI enabled PASS 16. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 17. boot 32-bit SMP Windows xp with ACPI enabled PASS 18. boot 32-bit Windows 2000 without ACPI PASS 19. boot 64-bit Windows xp with ACPI enabled PASS 20. boot 32-bit Windows xp without ACPI PASS 21. boot 64-bit UP vista PASS 22. boot 64-bit SMP vista PASS 23. kernel build in 32-bit linux guest OS PASS 24. kernel build in 64-bit linux guest OS PASS 25. LTP on 32-bit linux guest OS PASS 26. LTP on 64-bit linux guest OS PASS 27. boot 64-bit guests with ACPI enabled PASS 28. boot 32-bit x-server PASS 29. boot 64-bit SMP windows XP with ACPI enabled PASS 30. boot 64-bit SMP windows 2003 with ACPI enabled PASS 31. boot 64-bit SMP windows 2008 with ACPI enabled PASS 32. live migration 64bit linux guests FAIL 33. live migration 32bit linux guests FAIL 34. reboot 32bit windows xp guest PASS 35. reboot 32bit windows xp guest PASS Report Summary on IA32e Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 15 11 4 0 0 Restart 3 3 0 0 0 gtest 23 21 2 0 0 ===================================================================== control_panel 15 11 4 0 0 :KVM_LM_64_g64 1 0 1 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_4G_guest_64_g64 1 1 0 0 0 :KVM_four_sguest_64_g64 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 1 0 0 0 :KVM_1500M_guest_64_gPAE 1 1 0 0 0 :KVM_SR_64_g64 1 0 1 0 0 :KVM_LM_64_gPAE 1 0 1 0 0 :KVM_256M_guest_64_g64 1 1 0 0 0 :KVM_1500M_guest_64_g64 1 1 0 0 0 :KVM_4G_guest_64_gPAE 1 1 0 0 0 :KVM_SR_64_gPAE 1 0 1 0 0 :KVM_256M_guest_64_gPAE 1 1 0 0 0 :KVM_two_winxp_64_gPAE 1 1 0 0 0 :KVM_four_dguest_64_gPAE 1 1 0 0 0 Restart 3 3 0 0 0 :BootTo64_64_g64 1 1 0 0 0 :Guest64_64_gPAE 1 1 0 0 0 :GuestPAE_64_g64 1 1 0 0 0 gtest 23 21 2 0 0 :boot_up_acpi_64_gPAE 1 1 0 0 0 :boot_up_noacpi_xp_64_gP 1 1 0 0 0 :boot_smp_acpi_xp_64_g64 1 0 1 0 0 :boot_base_kernel_64_gPA 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_smp_acpi_win2k_64_ 1 1 0 0 0 :boot_base_kernel_64_g64 1 1 0 0 0 :bootx_64_gPAE 1 1 0 0 0 :kb_nightly_64_gPAE 1 1 0 0 0 :ltp_nightly_64_g64 1 1 0 0 0 :boot_up_acpi_64_g64 1 1 0 0 0 :boot_up_noacpi_win2k_64 1 1 0 0 0 :boot_smp_acpi_xp_64_gPA 1 1 0 0 0 :boot_smp_vista_64_gPAE 1 1 0 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :bootx_64_g64 1 1 0 0 0 :boot_up_vista_64_g64 1 1 0 0 0 :boot_up_acpi_xp_64_g64 1 1 0 0 0 :boot_up_vista_64_gPAE 1 0 1 0 0 :ltp_nightly_64_gPAE 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_up_noacpi_win2k3_6 1 1 0 0 0 :kb_nightly_64_g64 1 1 0 0 0 ===================================================================== Total 41 35 6 0 0 Thanks Yunfeng |
|
From: SourceForge.net <no...@so...> - 2008-05-06 08:05:32
|
Bugs item #1958519, was opened at 2008-05-06 16:05 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=1958519&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: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: fails to build KVM modules against 2.6.26 kernel Initial Comment: Building KVM modules against 2.6.24 kernel is ok. But building against 2.6.26 kernel will fail. make -j20 -C /lib/modules/2.6.26-rc1-02049-g6307419/build M=`pwd` \ LINUXINCLUDE="-I`pwd`/include -Iinclude -I`pwd`/include-compat \ -include include/linux/autoconf.h" \ "$@" make[1]: Entering directory `/root/kvm' Building modules, stage 2. MODPOST 3 modules WARNING: "kvm_div64_u64" [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.ko] undefined! CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-amd.mod.o CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-intel.mod.o CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.mod.o In file included from <command line>:1: ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory In file included from <command line>:1: ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory In file included from <command line>:1: ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-intel.mod.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-amd.mod.o] Error 1 make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.mod.o] Error 1 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/root/kvm' make: *** [all] Error 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958519&group_id=180599 |
|
From: Amit S. <ami...@qu...> - 2008-05-06 07:38:05
|
On Tuesday 06 May 2008 03:05:30 Kay, Allen M wrote: > Following three patches contains vt-d support for pci passthrough. It > contains diff's base on Amit's 4/22 passthrough tree. > > The hardware environment used for this work is an Intel Weybridge system > (Q35). The passthrough device is an E1000 NIC. I'm still using irqhook > mechanism for interrupt injection as I had problem with irqchip > machanism. Following is the command line I used to start the guest. Can you tell me what the problem with in-kernel irqchip is? Last time you mentioned there was a warning that came up when the guest exited. That shouldn't have stopped it from working, though > /usr/local/bin/qemu-system-x86_64 -boot c -hda /etc/xen/fc5_32.img -m > 256 -net none -pcidevice e1000/01:00.0-16 -no-kvm-irqchip > > Remaining tasks include: > > 1) Generated vtd.o with kvm-intel.ko instead of kvm.ko. > 2) Make iommu hooks in generic code to be non-Intel specific This is a good idea but will need collaboration with a lot of vendors. > Let me know of your feedbacks. Thanks. > > Allen Amit |
|
From: Amit S. <ami...@qu...> - 2008-05-06 07:36:04
|
On Tuesday 06 May 2008 03:06:23 Kay, Allen M wrote:
> Kvm kernel changes.
>
> Signed-off-by: Allen M Kay <all...@in...>
> --- /dev/null
> +++ b/arch/x86/kvm/vtd.c
> @@ -0,0 +1,183 @@
> +
> +#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
> +
> +struct dmar_drhd_unit * dmar_find_matched_drhd_unit(struct pci_dev
> *dev);
> +struct dmar_domain * iommu_alloc_domain(struct intel_iommu *iommu);
> +void iommu_free_domain(struct dmar_domain *domain);
> +int domain_init(struct dmar_domain *domain, int guest_width);
> +int domain_context_mapping(struct dmar_domain *d,
> + struct pci_dev *pdev);
> +int domain_page_mapping(struct dmar_domain *domain, dma_addr_t iova,
> + u64 hpa, size_t size, int prot);
> +void detach_domain_for_dev(struct dmar_domain *domain, u8 bus, u8
> devfn);
> +struct dmar_domain * find_domain(struct pci_dev *pdev);
Please move these to a .h file and also prefix appropriate keywords:
domain_context_mapping is confusing and since it's an intel iommu-only thing,
use something like
intel_iommu_domain_context_mapping
> +int kvm_iommu_map_pages(struct kvm *kvm,
> + gfn_t base_gfn, unsigned long npages)
> +{
> + unsigned long gpa;
> + struct page *page;
> + hpa_t hpa;
> + int j, write;
> + struct vm_area_struct *vma;
> +
> + if (!kvm->arch.domain)
> + return 1;
> +
> + gpa = base_gfn << PAGE_SHIFT;
> + page = gfn_to_page(kvm, base_gfn);
> + hpa = page_to_phys(page);
> +
> + printk(KERN_DEBUG "kvm_iommu_map_page: gpa = %lx\n", gpa);
> + printk(KERN_DEBUG "kvm_iommu_map_page: hpa = %llx\n", hpa);
> + printk(KERN_DEBUG "kvm_iommu_map_page: size = %lx\n",
> + npages*PAGE_SIZE);
> +
> + for (j = 0; j < npages; j++) {
> + gpa += PAGE_SIZE;
> + page = gfn_to_page(kvm, gpa >> PAGE_SHIFT);
> + hpa = page_to_phys(page);
> + domain_page_mapping(kvm->arch.domain, gpa, hpa,
> PAGE_SIZE,
> + DMA_PTE_READ | DMA_PTE_WRITE);
> + vma = find_vma(current->mm, gpa);
> + if (!vma)
> + return 1;
*
> + write = (vma->vm_flags & VM_WRITE) != 0;
> + get_user_pages(current, current->mm, gpa,
> + PAGE_SIZE, write, 0, NULL, NULL);
You should put_page each of the user pages when freeing or exiting (in
unmap_guest), else a ref is held on each page and that's a lot of memory
leaked.
Also, this rules out any form of guest swapping. You should put_page in case a
balloon driver in the guest tries to free some pages for the host.
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(kvm_iommu_map_pages);
> +
> +static int kvm_iommu_map_memslots(struct kvm *kvm)
> +{
> + int i, status;
> + for (i = 0; i < kvm->nmemslots; i++) {
> + status = kvm_iommu_map_pages(kvm,
> kvm->memslots[i].base_gfn,
> + kvm->memslots[i].npages);
> + if (status)
> + return status;
*
> + }
> + return 0;
> +}
> +
> +int kvm_iommu_map_guest(struct kvm *kvm,
> + struct kvm_pci_passthrough_dev *pci_pt_dev)
> +{
> + struct dmar_drhd_unit *drhd;
> + struct dmar_domain *domain;
> + struct intel_iommu *iommu;
> + struct pci_dev *pdev = NULL;
> +
> + printk(KERN_DEBUG "kvm_iommu_map_guest: host bdf = %x:%x:%x\n",
> + pci_pt_dev->host.busnr,
> + PCI_SLOT(pci_pt_dev->host.devfn),
> + PCI_FUNC(pci_pt_dev->host.devfn));
> +
> + for_each_pci_dev(pdev) {
> + if ((pdev->bus->number == pci_pt_dev->host.busnr) &&
> + (pdev->devfn == pci_pt_dev->host.devfn))
> + goto found;
> + }
You can use pci_get_device instead of going through the list yourself.
> + goto not_found;
> +found:
> + pci_pt_dev->pdev = pdev;
> +
> + drhd = dmar_find_matched_drhd_unit(pdev);
> + if (!drhd) {
> + printk(KERN_ERR "kvm_iommu_map_guest: drhd == NULL\n");
> + goto not_found;
> + }
> +
> + printk(KERN_DEBUG "kvm_iommu_map_guest: reg_base_addr = %llx\n",
> + drhd->reg_base_addr);
> +
> + iommu = drhd->iommu;
> + if (!iommu) {
> + printk(KERN_ERR "kvm_iommu_map_guest: iommu == NULL\n");
> + goto not_found;
> + }
> + domain = iommu_alloc_domain(iommu);
> + if (!domain) {
> + printk(KERN_ERR "kvm_iommu_map_guest: domain ==
> NULL\n");
> + goto not_found;
> + }
> + if (domain_init(domain, DEFAULT_DOMAIN_ADDRESS_WIDTH)) {
> + printk(KERN_ERR "kvm_iommu_map_guest: domain_init()
> failed\n");
> + goto not_found;
Memory allocated in iommu_alloc_domain is leaked in this case
> + }
> + kvm->arch.domain = domain;
> + kvm_iommu_map_memslots(kvm);
*: You don't check for failure in mapping
> + domain_context_mapping(kvm->arch.domain, pdev);
> + return 0;
> +not_found:
> + return 1;
> +}
> +EXPORT_SYMBOL_GPL(kvm_iommu_map_guest);
> +
> +int kvm_iommu_unmap_guest(struct kvm *kvm)
> +{
> + struct dmar_domain *domain;
> + struct kvm_pci_pt_dev_list *entry;
> + struct pci_dev *pdev;
> +
> + list_for_each_entry(entry, &kvm->arch.domain->devices, list) {
> + printk(KERN_DEBUG "kvm_iommu_unmap_guest: %x:%x:%x\n",
> + entry->pt_dev.host.busnr,
> + PCI_SLOT(entry->pt_dev.host.devfn),
> + PCI_FUNC(entry->pt_dev.host.devfn));
> +
> + pdev = entry->pt_dev.pdev;
> +
> + if (pdev == NULL) {
> + printk("kvm_iommu_unmap_guest: pdev == NULL\n");
> + return 1;
> + }
> +
> + /* detach kvm dmar domain */
> + detach_domain_for_dev(kvm->arch.domain,
> + pdev->bus->number, pdev->devfn);
> +
> + /* now restore back linux iommu domain */
> + domain = find_domain(pdev);
> + if (domain)
> + domain_context_mapping(domain, pdev);
> + else
> + printk(KERN_DEBUG
> + "kvm_iommu_unmap_guest: domain ==
> NULL\n");
> + }
> + /* unmap guest memory in vt-d page table */
> + iommu_free_domain(kvm->arch.domain);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(kvm_iommu_unmap_guest);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a97d2e2..a877db2 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -257,6 +257,7 @@ static void kvm_free_pci_passthrough(struct kvm
> *kvm)
>
> list_del(&pci_pt_dev->list);
> }
> + kvm->arch.domain = NULL;
> }
>
> unsigned long segment_base(u16 selector)
> @@ -1846,6 +1847,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
> if (copy_from_user(&pci_pt_dev, argp, sizeof
> pci_pt_dev))
> goto out;
>
> + r = kvm_iommu_map_guest(kvm, &pci_pt_dev);
> + if (r)
> + goto out;
> +
> r = kvm_vm_ioctl_pci_pt_dev(kvm, &pci_pt_dev);
> if (r)
> goto out;
If the ioctl fails, you don't "unmap" the guest (and also leak memory). I
suggest you call the map guest routine after the ioctl since the ioctl also
checks if a similar device has already been added and populates the
structure. In that case, you should call kvm_free_pci_passthrough() on
unsuccessful iommu mapping
Looks like you're leaking memory and failing to unmap or free the domain in
all the error paths.
> @@ -4088,6 +4093,8 @@ static void kvm_free_vcpus(struct kvm *kvm)
>
> void kvm_arch_destroy_vm(struct kvm *kvm)
> {
> + if (kvm->arch.domain)
> + kvm_iommu_unmap_guest(kvm);
This condition can be checked for inside the unmap guest routine.
iommu_unmap_guest can be called unconditionally.
> kvm_free_pci_passthrough(kvm);
> kvm_free_pit(kvm);
> kfree(kvm->arch.vpic);
> diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
> index 4662d49..70248cb 100644
> --- a/include/asm-x86/kvm_host.h
> +++ b/include/asm-x86/kvm_host.h
> @@ -19,6 +19,8 @@
> #include <linux/kvm_types.h>
>
> #include <asm/desc.h>
> +#include <linux/dmar.h>
> +#include <linux/intel-iommu.h>
>
> #define KVM_MAX_VCPUS 16
> #define KVM_MEMORY_SLOTS 32
> @@ -318,6 +320,7 @@ struct kvm_arch{
> */
> struct list_head active_mmu_pages;
> struct list_head pci_pt_dev_head;
> + struct dmar_domain *domain;
Use a descriptive name, like intel_iommu_domain.
> struct kvm_pic *vpic;
> struct kvm_ioapic *vioapic;
> struct kvm_pit *vpit;
> diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
> index 5f93b78..6202ed1 100644
> --- a/include/asm-x86/kvm_para.h
> +++ b/include/asm-x86/kvm_para.h
> @@ -170,5 +170,6 @@ struct kvm_pci_pt_info {
> struct kvm_pci_passthrough_dev {
> struct kvm_pci_pt_info guest;
> struct kvm_pci_pt_info host;
> + struct pci_dev *pdev; /* kernel device pointer for host dev
> */
> };
> #endif
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 4e16682..bcfcf78 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -276,6 +276,12 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v);
> int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
> void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
>
> +int kvm_iommu_map_pages(struct kvm *kvm, gfn_t base_gfn,
> + unsigned long npages);
> +int kvm_iommu_map_guest(struct kvm *kvm,
> + struct kvm_pci_passthrough_dev *pci_pt_dev);
> +int kvm_iommu_unmap_guest(struct kvm *kvm);
> +
Why can't these be put in asm-x86/kvm_host.h?
> static inline void kvm_guest_enter(void)
> {
> account_system_vtime(current);
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d3cb4cc..e46614a 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -309,6 +309,9 @@ int __kvm_set_memory_region(struct kvm *kvm,
> new.npages = npages;
> new.flags = mem->flags;
>
> + /* map the pages in iommu page table */
(if one exists)
> + kvm_iommu_map_pages(kvm, base_gfn, npages);
> +
You should do this once all the memory is set up properly (which is just
before returning 0)
> /* Disallow changing a memory slot's size. */
> r = -EINVAL;
> if (npages && old.npa
Amit
|
|
From: DVD д. <sl...@bo...> - 2008-05-06 06:46:28
|
Купите на выходные КИНО!!! Цена от 100 до 80 рублей за диск! (в зависимости от количества) Отличное качество! (DVD-9, звук DD 5.1, бонусы) Большой выбор! (наше, иностранное, мультфильмы, сборники) Доставка по Москве, отправка почтой по всей России! Добро пожаловать http://www.dvdservicce.ru |
|
From: SourceForge.net <no...@so...> - 2008-05-06 06:36:26
|
Bugs item #1958467, was opened at 2008-05-06 14:36 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=1958467&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: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Fail to save restore and live migrate on 32e platform Initial Comment: Environment: ------------ Host OS: RHEL5U1 ia32e Commits: 630741928b4a7eeff27e134d7ba7bc2fc2c764c5-77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3 Hardware:Platform Woodcrest CPU 4 Memory size 8G' Bug detailed description: -------------------------- Fail to save restore and live migrate on 32e platform. When restore the guest, the new qemu disappeared, host console print: qemu: warning: error while loading state for instance 0x0 of device 'cpu' Migration failed rc=215 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/sr qemu-system-x86_64 -m 256 -monitor pty -net nic,macaddr=00:16:3e:35:1c:97,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/sr 2.ctrl+alt+2 switch to qemu monitor and save the guest migrate file:///share/xvs/var/sr123 3.restore 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/sr -incoming file:///share/xvs/var/sr123 Current result: ---------------- Expected result: ---------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&group_id=180599 |
|
From: SourceForge.net <no...@so...> - 2008-05-06 06:34:28
|
Bugs item #1958464, was opened at 2008-05-06 14:34 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=1958464&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: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: "Unknown symbol in module" loading kvm.ko Initial Comment: With today's commits, kvm.git 630741928b4a7eeff27e134d7ba7bc2fc2c764c5 and kvm-userspace.git 77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3. , I cannot insert PAE KVM modules. Lots of unknown symbols have been reported while inserting kvm.ko. error inserting '/usr/kvm/kvm.ko': -1 Unknown symbol in module dmesg: kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva kvm: Unknown symbol kvm_div64_u64 kvm: emulating preempt notifiers; do not benchmark on this machine loaded kvm module (kvm-67-2059-g9cebc1e) kvm: Unknown symbol kvm_div64_u64 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_id=180599 |
|
From: Yunfeng Z. <yun...@in...> - 2008-05-06 02:03:32
|
With today's tip, I cannot insert PAE KVM modules. Lots of unknown symbols have been reported while inserting kvm.ko. error inserting '/usr/kvm/kvm.ko': -1 Unknown symbol in module dmesg: kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva kvm: Unknown symbol kvm_div64_u64 kvm: emulating preempt notifiers; do not benchmark on this machine loaded kvm module (kvm-67-2059-g9cebc1e) kvm: Unknown symbol kvm_div64_u64 |
|
From: Alexander G. <ag...@su...> - 2008-05-05 23:16:29
|
On May 4, 2008, at 9:56 AM, Avi Kivity wrote: > Marcelo Tosatti wrote: >> Add three PCI bridges to support 128 slots. >> >> Changes since v1: >> - Remove I/O address range "support" (so standard PCI I/O space is >> used). >> - Verify that there's no special quirks for 82801 PCI bridge. >> - Introduce separate flat IRQ mapping function for non-SPARC targets. >> >> > > I've cooled off on the 128 slot stuff, mainly because most real hosts > don't have them. An unusual configuration will likely lead to > problems > as most guest OSes and workloads will not have been tested thoroughly > with them. This is more of a "let's do this conditionally" than a "let's not do it" reason imho. > - it requires a large number of interrupts, which are difficult to > provide, and which it is hard to ensure all OSes support. MSI is > relatively new. We could just as well extend the device layout to have every device be attached to one virtual IOAPIC pin, so we'd have like 128 / 4 = 32 IOAPICs in the system and one interrupt for each device. > - is only a few interrupts are available, then each interrupt requires > scanning a large number of queues This case should be rare, basically only existent with OSs that don't support APIC properly. > If we are to do this, then we need better tests than "80 disks show > up". True. > The alternative approach of having the virtio block device control > up to > 16 disks allows having those 80 disks with just 5 slots (and 5 > interrupts). This is similar to the way traditional SCSI controllers > behave, and so should not surprise the guest OS. The one thing I'm actually really missing here is use cases. What are we doing this for? And further along the line, are there other approaches to the problems for which this was supposed to be a solution? Maybe someone can raise a case where it's not virtblk / virtnet. Alex |
|
From: Anthony L. <an...@co...> - 2008-05-05 22:53:48
|
Avi Kivity wrote: > Marcelo Tosatti wrote: > >> Add three PCI bridges to support 128 slots. >> >> Changes since v1: >> - Remove I/O address range "support" (so standard PCI I/O space is used). >> - Verify that there's no special quirks for 82801 PCI bridge. >> - Introduce separate flat IRQ mapping function for non-SPARC targets. >> >> >> > > I've cooled off on the 128 slot stuff, mainly because most real hosts > don't have them. An unusual configuration will likely lead to problems > as most guest OSes and workloads will not have been tested thoroughly > with them. > > - it requires a large number of interrupts, which are difficult to > provide, and which it is hard to ensure all OSes support. MSI is > relatively new. > - is only a few interrupts are available, then each interrupt requires > scanning a large number of queues > > If we are to do this, then we need better tests than "80 disks show up". > > The alternative approach of having the virtio block device control up to > 16 disks allows having those 80 disks with just 5 slots (and 5 > interrupts). This is similar to the way traditional SCSI controllers > behave, and so should not surprise the guest OS. > If you have a single virtio-blk device that shows up as 8 functions, we could achieve the same thing. We can cheat with the interrupt handlers to avoid cache line bouncing too. Plus, we can use PCI hotplug so we don't have to reinvent a new hotplug mechanism. I'm inclined to think that ring sharing isn't as useful as it seems as long as we don't have indirect scatter gather lists. Regards, Anthony Liguori |
|
From: Alexander G. <ag...@su...> - 2008-05-05 22:47:03
|
On May 4, 2008, at 9:56 AM, Avi Kivity wrote: > Marcelo Tosatti wrote: >> Add three PCI bridges to support 128 slots. >> >> Changes since v1: >> - Remove I/O address range "support" (so standard PCI I/O space is >> used). >> - Verify that there's no special quirks for 82801 PCI bridge. >> - Introduce separate flat IRQ mapping function for non-SPARC targets. >> >> > > I've cooled off on the 128 slot stuff, mainly because most real hosts > don't have them. An unusual configuration will likely lead to > problems > as most guest OSes and workloads will not have been tested thoroughly > with them. This is more of a "let's do this conditionally" than a "let's not do it" reason imho. > - it requires a large number of interrupts, which are difficult to > provide, and which it is hard to ensure all OSes support. MSI is > relatively new. We could just as well extend the device layout to have every device be attached to one virtual IOAPIC pin, so we'd have like 128 / 4 = 32 IOAPICs in the system and one interrupt for each device. > - is only a few interrupts are available, then each interrupt requires > scanning a large number of queues This case should be rare, basically only existent with OSs that don't support APIC properly. > If we are to do this, then we need better tests than "80 disks show > up". True. > The alternative approach of having the virtio block device control > up to > 16 disks allows having those 80 disks with just 5 slots (and 5 > interrupts). This is similar to the way traditional SCSI controllers > behave, and so should not surprise the guest OS. The one thing I'm actually really missing here is use cases. What are we doing this for? And further along the line, are there other approaches to the problems for which this was supposed to be a solution? Maybe someone can raise a case where it's not virtblk / virtnet. Alex |
157 messages has been excluded from this view by a project administrator.
