Questions about creating virtual disks with qemu/kvm
Hi all,
I hava some doubts about creating virtual disks under qemu/kvm:
a) is it possible to share disks between virtual guests like vmware
server, esx and xen does?? for example to setup a virtual cluster with
two or more nodes using Red Hat Cluster Suite.
b) Can I split virtual disks with some determined length? For example
create an 8 GB virtual disk split on 2GB files with or without
allocating all disk space ...
Many thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] don't call adjust_vmx_controls() second time
On 08/27/2009 11:42 PM, Andrew Theurer wrote: On Thu, 2009-08-27 at 19:21 +0300, Avi Kivity wrote: On 08/27/2009 06:41 PM, Gleb Natapov wrote: Don't call adjust_vmx_controls() two times for the same control. It restores options that was dropped earlier. Applied, thanks. Andrew, if you rerun your benchmark atop kvm.git 'next' branch, I believe you will see dramatically better results. Yes! CPU is much lower: user nice system irq softirq guest idle iowait 5.81 0.009.48 0.081.04 21.32 57.864.41 previous CPU: user nice system irq softirq guest idle iowait 5.67 0.00 11.64 0.09 1.05 31.90 46.063.59 How does it compare to the other hypervisor now? new oprofile: samples %app name symbol name 885444 53.2905 kvm-intel.ko vmx_vcpu_run guest mode = good 38090 2.2924 qemu-system-x86_64 cpu_physical_memory_rw 34764 2.0923 qemu-system-x86_64 phys_page_find_alloc 14730 0.8865 qemu-system-x86_64 qemu_get_ram_ptr 10814 0.6508 vmlinux-2.6.31-rc5-autokern1 copy_user_generic_string 10871 0.6543 qemu-system-x86_64 virtqueue_get_head 8557 0.5150 qemu-system-x86_64 virtqueue_avail_bytes 7173 0.4317 qemu-system-x86_64 lduw_phys 4122 0.2481 qemu-system-x86_64 ldl_phys 3339 0.2010 qemu-system-x86_64 virtqueue_num_heads 4129 0.2485 libpthread-2.5.sopthread_mutex_lock virtio and related qemu overhead: 8.2%. 25278 1.5214 vmlinux-2.6.31-rc5-autokern1 native_write_msr_safe 12278 0.7390 vmlinux-2.6.31-rc5-autokern1 native_read_msr_safe This will be reduced to if we move virtio to kernel context. 12380 0.7451 vmlinux-2.6.31-rc5-autokern1 native_set_debugreg 3550 0.2137 vmlinux-2.6.31-rc5-autokern1 native_get_debugreg A lot less than before, but still annoying. 4631 0.2787 vmlinux-2.6.31-rc5-autokern1 mwait_idle idle=halt may improve this, mwait is slow. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-88: KVM_APIC_READ: read reserved register b0
Daniel Bareiro wrote: On Friday, 28 August 2009 12:04:02 +0200, Christoph Lechner wrote: Hi all, Hi Christoph. Hi. running kvm-88 on a 2.6.26-1-amd64 kernel (stock Debian 5.0 kernel), I get the syslog on the host system flooded with the message: Aug 28 11:49:40 reactor kernel: [124035.611782] KVM_APIC_READ: read reserved register b0 [...] Also I am observing this behavior in one of my hosts with KVM-88 and Linux 2.6.30 compiled both by myself on Ubuntu GNU/Linux Hardy Heron server amd64, as I've mentioned in a previous [1] mail. Guests has Debian GNU/Linux Lenny with stock kernel 2.6.26. I was trying if with model=virtio the problem were solved, but was not successful. It would seem that the cause is due to something related to hardware of the host (is it possible?), since I have other hosts in which I use both the same version of KVM and kernel, also both compiled by myself, and I'm not having this problem. don't know if this is caused by the host hardware. But what I forgot to mention: I commented out the printk call in lapic.c. This stopped the flooding, but I know it's only a work around. - cl -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-88: KVM_APIC_READ: read reserved register b0
On Sun, Aug 30, 2009 at 11:59:27AM +0200, Christoph Lechner wrote: Daniel Bareiro wrote: On Friday, 28 August 2009 12:04:02 +0200, Christoph Lechner wrote: Hi all, Hi Christoph. Hi. running kvm-88 on a 2.6.26-1-amd64 kernel (stock Debian 5.0 kernel), I get the syslog on the host system flooded with the message: Aug 28 11:49:40 reactor kernel: [124035.611782] KVM_APIC_READ: read reserved register b0 [...] Also I am observing this behavior in one of my hosts with KVM-88 and Linux 2.6.30 compiled both by myself on Ubuntu GNU/Linux Hardy Heron server amd64, as I've mentioned in a previous [1] mail. Guests has Debian GNU/Linux Lenny with stock kernel 2.6.26. I was trying if with model=virtio the problem were solved, but was not successful. It would seem that the cause is due to something related to hardware of the host (is it possible?), since I have other hosts in which I use both the same version of KVM and kernel, also both compiled by myself, and I'm not having this problem. don't know if this is caused by the host hardware. But what I forgot to mention: I commented out the printk call in lapic.c. This stopped the flooding, but I know it's only a work around. This printk no longer exists in upstream kvm. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-88: KVM_APIC_READ: read reserved register b0
Gleb Natapov wrote: This printk no longer exists in upstream kvm. just to be curious: What was the reason to add that debugging message? I don't know much about the background of the message, but I assume that it is useful. So wouldn't it be a idea to keep the code for the message where it is and just throttle the rate it is reported? - cl -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-88: KVM_APIC_READ: read reserved register b0
On Sun, Aug 30, 2009 at 01:42:14PM +0200, Christoph Lechner wrote: Gleb Natapov wrote: This printk no longer exists in upstream kvm. just to be curious: What was the reason to add that debugging message? Because well behaved OS shouldn't read write only register. Unfortunately older Linux kernels sometimes uses xchg to access eoi(b0) apic register which will generate read/write. I don't know much about the background of the message, but I assume that it is useful. So wouldn't it be a idea to keep the code for the message where it is and just throttle the rate it is reported? It's not too much useful unless you are debugging a guest. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Extending virtio_console to support multiple ports
Amit Shah wrote: I did think about that as well, but there are problems: - vnc clients (at least tigervnc) wants to receive the entire clipboard in a single flush command. So in the pre-allocated buffers scenario we could run short of the available buffers in some cases. So there will have to be a flag with each buffer that says 'there's more data pending for this particular write' which will have to be passed on to qemu and qemu will then flush it once it receives all the data No flags, assume it's a streaming protocol and don't assume anything about message sizes. IOW, when you send clipboard data, send size and then the data. QEMU consumes bytes until it reaches size. - A lock has to be introduced to fetch one unused buffer from the list and pass it on to the host. And this lock has to be a spinlock, just because writes can be called from irq context. I don't see a problem here. Regards, Anthony Liguori Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Extending virtio_console to support multiple ports
On (Sun) Aug 30 2009 [07:48:37], Anthony Liguori wrote: Amit Shah wrote: I did think about that as well, but there are problems: - vnc clients (at least tigervnc) wants to receive the entire clipboard in a single flush command. So in the pre-allocated buffers scenario we could run short of the available buffers in some cases. So there will have to be a flag with each buffer that says 'there's more data pending for this particular write' which will have to be passed on to qemu and qemu will then flush it once it receives all the data No flags, assume it's a streaming protocol and don't assume anything about message sizes. IOW, when you send clipboard data, send size and then the data. QEMU consumes bytes until it reaches size. Same intent but a different method: I'll have to specify that particular data is size and that data after this special data is the actual data stream. - A lock has to be introduced to fetch one unused buffer from the list and pass it on to the host. And this lock has to be a spinlock, just because writes can be called from irq context. I don't see a problem here. You mean you don't see a problem in using a spinlock vs not using one? Userspace will typically send the entire buffer to be transmitted in one system call. If it's large, the system call will have to be broken into several. This results in multiple guest system calls, each one to be handled with a spinlock held. Compare this with the entire write handled in one system call in the current method. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-88: KVM_APIC_READ: read reserved register b0
On Sunday, 30 August 2009 14:49:59 +0300, Gleb Natapov wrote: This printk no longer exists in upstream kvm. Between emails of the list, I found the suggestion to apply this [1] patch, but I suppose that not yet it must be applied in the download version. just to be curious: What was the reason to add that debugging message? Because well behaved OS shouldn't read write only register. Unfortunately older Linux kernels sometimes uses xchg to access eoi(b0) apic register which will generate read/write. According to I see, guest kernel is 2.6.26-2-486. Apparently, after a reboot, the OS boots with it instead of amd64 kernel. After boot with amd64 kernel, no longer flooding in syslog takes place. I didn't test yet, but I think that with a 686 kernel also the problem had been solved from the moment that the kernel is nearer the hardware architecture which I'm using. Thanks to both for your replies. Regards, Daniel [1] http://thread.gmane.org/gmane.comp.emulators.qemu/24029 -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 signature.asc Description: Digital signature
Problem getting virtio storage and network to work
Hi, I saw the anouncement from redhat and tried to download with no succes. The File Links under http://www.linux-kvm.org/page/WindowsGuestDrivers/Last_WHQLed_drivers are dead. Could this one be fixed ? Thanks -- Thomas Heil - ! note my new number ! Skype: phiber.sun Email: thomas.h...@artofcoding.de -- -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TOOL] c2kpe: C expression to kprobe event format converter
On Thu, Aug 13, 2009 at 04:59:19PM -0400, Masami Hiramatsu wrote:
This program converts probe point in C expression to kprobe event
format for kprobe-based event tracer. This helps to define kprobes
events by C source line number or function name, and local variable
name. Currently, this supports only x86(32/64) kernels.
Compile
Before compilation, please install libelf and libdwarf development
packages.
(e.g. elfutils-libelf-devel and libdwarf-devel on Fedora)
This may probably need a specific libdwarf version?
c2kpe.c: In function ‘die_get_entrypc’:
c2kpe.c:422: erreur: ‘Dwarf_Ranges’ undeclared (first use in this function)
c2kpe.c:422: erreur: (Each undeclared identifier is reported only once
c2kpe.c:422: erreur: for each function it appears in.)
c2kpe.c:422: erreur: ‘ranges’ undeclared (first use in this function)
c2kpe.c:447: attention : implicit declaration of function ‘dwarf_get_ranges’
c2kpe.c:451: attention : implicit declaration of function ‘dwarf_ranges_dealloc’
TODO
- Fix bugs.
- Support multiple probepoints from stdin.
- Better kmodule support.
- Use elfutils-libdw?
- Merge into trace-cmd or perf-tools?
Yeah definetly, that would be a veeery interesting thing to have.
I've played with kprobe ftrace to debug something this evening.
It's very cool to be able to put dynamic tracepoints in desired places.
But...
I firstly needed to put random trace_printk() in some places to
observe some variables values. And then I thought about the kprobes
tracer and realized I could do that without the need of rebuilding
my kernel. Then I've played with it and indeed it works well and
it's useful, but at the cost of reading objdump based assembly
code to find the places where I could find my variables values.
And after two or three probes in such conditions, I've become
tired of that, then I wanted to try this tool.
While I cannot yet because of this build error, I can imagine
the power of such facility from perf.
We could have a perf probe that creates a kprobe event in debugfs
(default enable = 0) and which then rely on perf record for the actual
recording.
Then we could analyse it through perf trace.
Let's imagine a simple example:
int foo(int arg1, int arg2)
{
int var1;
var1 = arg1;
var1 *= arg2;
var1 -= arg1;
-- insert a probe here (file bar.c : line 60)
var1 ^= ...
return var1;
}
./perf kprobe --file bar.c:60 --action arg1=%d,arg2=%d,var1=%d -- ls -R /
./perf trace
arg1=1 arg2=1 var1=0
arg1=2 arg2=2 var1=2
etc..
You may want to sort by field:
./perf trace -s arg1 --order desc
arg1=1
|
--- arg2=1 var=1
|
--- arg2=2 var=1
arg1=2
|
--- arg2=1 var=0
|
--- [...]
./perf trace -s arg1,arg2 --order asc
arg1=1
|
--- arg2=1
|
- var1=0
|
- var1=
arg2=...
|
Ok the latter is a bad example because var1 will always have only one
value for a given arg1 and arg2. But I guess you see the point.
You won't have to care about the perf trace part, it's already
implemented and I'll soon handle the sorting part.
All we need is the perf kprobes that translate a C level
probing expression to a /debug/tracing/kprobe_events compliant
thing. And then just call perf record with the new created
event as an argument.
Frederic.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: R/W HG memory mappings with kvm?
On Thu, Aug 27, 2009 at 4:08 PM, Avi Kivitya...@redhat.com wrote: On 08/27/2009 05:34 AM, Stephen Donnelly wrote: On Mon, Aug 24, 2009 at 4:55 PM, Avi Kivitya...@redhat.com wrote: On 08/24/2009 12:59 AM, Stephen Donnelly wrote: On Thu, Aug 20, 2009 at 12:14 AM, Avi Kivitya...@redhat.com wrote: On 08/13/2009 07:07 AM, Stephen Donnelly wrote: npages = get_user_pages_fast(addr, 1, 1, page); returns -EFAULT, presumably because (vma-vm_flags (VM_IO | VM_PFNMAP)). It takes then unlikely branch, and checks the vma, but I don't understand what it is doing here: pfn = ((addr - vma-vm_start) PAGE_SHIFT) + vma-vm_pgoff; It's calculating the pfn according to pfnmap rules. From what I understand this will only work when remapping 'main memory', e.g. where the pgoff is equal to the physical page offset? VMAs that remap IO memory will usually set pgoff to 0 for the start of the mapping. If so, how do they calculate the pfn when mapping pages? kvm needs to be able to do the same thing. If the vma-vm_file is /dev/mem, then the pg_off will map to physical addresses directly (at least on x86), and the calculation works. If the vma is remapping io memory from a driver, then vma-vm_file will point to the device node for that driver. Perhaps we can do a check for this at least? We can't duplicate mm/ in kvm. However, mm/memory.c says: * The way we recognize COWed pages within VM_PFNMAP mappings is through the * rules set up by remap_pfn_range(): the vma will have the VM_PFNMAP bit * set, and the vm_pgoff will point to the first PFN mapped: thus every special * mapping will always honor the rule * * pfn_of_page == vma-vm_pgoff + ((addr - vma-vm_start) PAGE_SHIFT) * * And for normal mappings this is false. So it seems the kvm calculation is right and you should set vm_pgoff in your driver. That may be true for COW pages, which are main memory, but I don't think it is true for device drivers. In a device driver the mmap function receives the vma from the OS. The vm_pgoff field contains the offset area in the file. For drivers this is used to determine where to start the map compared to the io base address. If the driver is mapping io memory to user space it calls io_remap_pfn_range with the pfn for the io memory. The remap_pfn_range call sets the VM_IO and VM_PFNMAP bits in vm_flags. It does not alter the vm_pgoff value. A simple example is hpet_mmap() in drivers/char/hpet.c, or mbcs_gscr_mmap() in drivers/char/mbcs.c. I'm still not sure how genuine IO memory (mapped from a driver to userspace with remap_pfn_range or io_remap_page_range) could be mapped into kvm though. If it can be mapped to userspace, it can be mapped to kvm. We just need to synchronize the rules. We can definitely map it into userspace. The problem seems to be how the kvm kernel module translates the guest pfn back to a host physical address. Is there a kernel equivalent of mmap? do_mmap(), but don't use it. Use mmap() from userspace like everyone else. Of course you are right, gfn_to_pfn is in user space. There is already a mapping of the memory to the process (from qemu_ram_mmap), the question is how to look it up. Regards, Stephen. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TOOL] c2kpe: C expression to kprobe event format converter
Frederic Weisbecker wrote:
On Thu, Aug 13, 2009 at 04:59:19PM -0400, Masami Hiramatsu wrote:
This program converts probe point in C expression to kprobe event
format for kprobe-based event tracer. This helps to define kprobes
events by C source line number or function name, and local variable
name. Currently, this supports only x86(32/64) kernels.
Compile
Before compilation, please install libelf and libdwarf development
packages.
(e.g. elfutils-libelf-devel and libdwarf-devel on Fedora)
This may probably need a specific libdwarf version?
c2kpe.c: In function ‘die_get_entrypc’:
c2kpe.c:422: erreur: ‘Dwarf_Ranges’ undeclared (first use in this function)
c2kpe.c:422: erreur: (Each undeclared identifier is reported only once
c2kpe.c:422: erreur: for each function it appears in.)
c2kpe.c:422: erreur: ‘ranges’ undeclared (first use in this function)
c2kpe.c:447: attention : implicit declaration of function ‘dwarf_get_ranges’
c2kpe.c:451: attention : implicit declaration of function
‘dwarf_ranges_dealloc’
Aah, sure, it should be compiled with libdwarf newer than 20090324.
You can find it in http://reality.sgiweb.org/davea/dwarf.html
BTW, libdwarf and libdw (which is the yet another implementation of
dwarf library) are still under development, e.g. libdwarf doesn't
support gcc-4.4.1(very new) and only the latest libdw(0.142) can
support it. So, perhaps I might better port it on libdw, even that is
less documented...:(
TODO
- Fix bugs.
- Support multiple probepoints from stdin.
- Better kmodule support.
- Use elfutils-libdw?
- Merge into trace-cmd or perf-tools?
Yeah definetly, that would be a veeery interesting thing to have.
I've played with kprobe ftrace to debug something this evening.
It's very cool to be able to put dynamic tracepoints in desired places.
But...
I firstly needed to put random trace_printk() in some places to
observe some variables values. And then I thought about the kprobes
tracer and realized I could do that without the need of rebuilding
my kernel. Then I've played with it and indeed it works well and
it's useful, but at the cost of reading objdump based assembly
code to find the places where I could find my variables values.
And after two or three probes in such conditions, I've become
tired of that, then I wanted to try this tool.
While I cannot yet because of this build error, I can imagine
the power of such facility from perf.
We could have a perf probe that creates a kprobe event in debugfs
(default enable = 0) and which then rely on perf record for the actual
recording.
Then we could analyse it through perf trace.
Let's imagine a simple example:
int foo(int arg1, int arg2)
{
int var1;
var1 = arg1;
var1 *= arg2;
var1 -= arg1;
-- insert a probe here (file bar.c : line 60)
var1 ^= ...
return var1;
}
./perf kprobe --file bar.c:60 --action arg1=%d,arg2=%d,var1=%d -- ls -R
/
I recommend it should be separated from record, like below:
# set new event
./perf kprobe --add kprobe:event1 --file bar.c:60 --action
arg1=%d,arg2=%d,var1=%d
# record new event
./perf record -e kprobe:event1 -a -R -- ls -R /
This will allow us to focus on one thing -- convert C to kprobe-tracer.
And also, it can be listed as like as tracepoint events.
./perf trace
arg1=1 arg2=1 var1=0
arg1=2 arg2=2 var1=2
etc..
You may want to sort by field:
./perf trace -s arg1 --order desc
arg1=1
|
--- arg2=1 var=1
|
--- arg2=2 var=1
arg1=2
|
--- arg2=1 var=0
|
--- [...]
./perf trace -s arg1,arg2 --order asc
arg1=1
|
--- arg2=1
|
- var1=0
|
- var1=
arg2=...
|
Ok the latter is a bad example because var1 will always have only one
value for a given arg1 and arg2. But I guess you see the point.
You won't have to care about the perf trace part, it's already
implemented and I'll soon handle the sorting part.
All we need is the perf kprobes that translate a C level
probing expression to a /debug/tracing/kprobe_events compliant
thing. And then just call perf record with the new created
event as an argument.
Indeed, that's what I imagine.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2847560 ] Guest hang with exhausted IRQ sources error if 8 VFs assigne
Bugs item #2847560, was opened at 2009-08-30 22:58 Message generated for change (Tracker Item Submitted) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2847560group_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: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: Guest hang with exhausted IRQ sources error if 8 VFs assigne Initial Comment: Environment: Host OS (ia32/ia32e/IA64): ia32e Guest OS (ia32/ia32e/IA64): ia32e Guest OS Type (Linux/Windows): Linux kvm.git Commit: 779cc54dbccaa3a00d70a9d61d090be5d9ccc903 qemu-kvm Commit: 9e3269181e9bc56feb43bcd4e8ce0b82cd543e65 Host Kernel Version: 2.6.31-rc5 Hardware: NHM-EP Bug detailed description: -- If boot a guest with 8 VFs assigned, guest will hang at stage of Starting udev:. And dmesg will shows that kvm: exhaust allocatable IRQ sources! If boot a guest with 6 VFs assigned, guest can boot up and VF can work well in guest. Dmesg info: pci-stub :01:10.0: enabling device ( - 0002) assign device: host bdf = 1:10:0 pci-stub :01:10.1: enabling device ( - 0002) assign device: host bdf = 1:10:1 pci-stub :01:10.2: enabling device ( - 0002) assign device: host bdf = 1:10:2 pci-stub :01:10.3: enabling device ( - 0002) assign device: host bdf = 1:10:3 pci-stub :01:10.4: enabling device ( - 0002) assign device: host bdf = 1:10:4 pci-stub :01:10.5: enabling device ( - 0002) assign device: host bdf = 1:10:5 pci-stub :01:10.6: enabling device ( - 0002) assign device: host bdf = 1:10:6 pci-stub :01:10.7: enabling device ( - 0002) assign device: host bdf = 1:10:7 pci-stub :01:10.0: irq 91 for MSI/MSI-X pci-stub :01:10.0: irq 92 for MSI/MSI-X pci-stub :01:10.0: irq 93 for MSI/MSI-X pci-stub :01:10.1: irq 97 for MSI/MSI-X pci-stub :01:10.1: irq 98 for MSI/MSI-X pci-stub :01:10.1: irq 99 for MSI/MSI-X pci-stub :01:10.2: irq 100 for MSI/MSI-X pci-stub :01:10.2: irq 101 for MSI/MSI-X pci-stub :01:10.2: irq 102 for MSI/MSI-X pci-stub :01:10.3: irq 103 for MSI/MSI-X pci-stub :01:10.3: irq 104 for MSI/MSI-X pci-stub :01:10.3: irq 105 for MSI/MSI-X pci-stub :01:10.4: irq 106 for MSI/MSI-X pci-stub :01:10.4: irq 107 for MSI/MSI-X pci-stub :01:10.4: irq 108 for MSI/MSI-X pci-stub :01:10.5: irq 112 for MSI/MSI-X pci-stub :01:10.5: irq 113 for MSI/MSI-X pci-stub :01:10.5: irq 114 for MSI/MSI-X pci-stub :01:10.6: irq 115 for MSI/MSI-X pci-stub :01:10.6: irq 116 for MSI/MSI-X pci-stub :01:10.6: irq 117 for MSI/MSI-X kvm: exhaust allocatable IRQ sources! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2847560group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
