qemu KVM VM replication dirty log question.
Hello KVM developers, I have a question about the dirty log mechanism in qemu. I am doing some research on multi-core VM fault tolerance and I extended qemu to do checkpoint-restart based replication (something similar to the Remus project on Xen). I am using a great amount of the live migration code, particularly the dirty page tracking mechanism. However, when I run a multi-core (up to 16 cores) VM in dirty log mode I see significant slowdown of the dirty page tracking. I identified that the problem is in the cpu_physical_memory_reset_dirty() function which iterates all vcpu's soft-mmu TLB entries, essentially for every single address that was reported as dirty by the kernel. My understanding is that dirty page tracking is carried out entirely by the KVM kernel module in case two dimensional page tables are supported by the hardware (I have NPT enabled). This log is then synchronized with userspace in the cpu_physical_sync_dirty_bitmap() function which updates the ram_list.phys_dirty buffer in qemu. Could someone explain/confirm why is it necessary to clear the soft-mmu TLBs in cpu_physical_memory_reset_dirty() ? Are those being used in case of tdp? I suspect it's unnecessary if the hardware supports MMU virtualization. I modified this code to clear only ram_list.phys_dirty and ran a couple of tests on live migrating multi-core VMs in such way, they seem to work fine and I get much better dirty-log performance. (This is important when doing replication because the VM has to be executed in log-dirty mode at all times.) Please let me know if I am missing something! I run vanilla kernel 2.6.37 with the latest qemu version from the git repository (version 0.14.50 (qemu-kvm-devel)). My hardware config is: processor : 15 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : Quad-Core AMD Opteron(tm) Processor 8378 stepping : 2 cpu MHz : 2400.401 cache size : 512 KB physical id : 3 siblings : 4 core id : 3 cpu cores : 4 apicid : 15 initial apicid : 15 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save bogomips : 4800.25 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate and I have NPT support enabled in the KVM kernel module. Thanks, Balazs -- 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
qemu-kvm 0.14.0 oom
This is something that's plagued me for many versions. I've read the bug reports where this was marked as fixed back in version 12.x Currently with Kernel 2.6.37.4 64bit. modinfo kvm filename: /lib/modules/2.6.37.4/kernel/arch/x86/kvm/kvm.ko license:GPL author: Qumranet depends: vermagic: 2.6.37.4 SMP mod_unload parm: oos_shadow:bool parm: ignore_msrs:bool modinfo kvm-amd filename: /lib/modules/2.6.37.4/kernel/arch/x86/kvm/kvm-amd.ko license:GPL author: Qumranet depends:kvm vermagic: 2.6.37.4 SMP mod_unload parm: npt:int parm: nested:int cli used (drive image is raw format) - qemu-system-x86_64 -cpu core2duo -smp 2 -hda test -m 2048 -net user -net nic,model=e1000 -usb -usbdevice tablet -vnc :0 -boot c [673051.444876] Out of memory: Kill process 23037 (qemu-system-x86) score 778 or sacrifice child [673051.444879] Killed process 23037 (qemu-system-x86) total-vm:7418732kB, anon-rss:6018088kB, file-rss:0kB With a RAM amount of 2GiB specified, qemu-kvm will continue to consume RAM until 7GIB physical and 2GiB swap is exhausted. Using this CPU - processor : 3 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X4 620 Processor stepping: 2 cpu MHz : 2611.759 cache size : 512 KB physical id : 0 siblings: 4 core id : 2 cpu cores : 4 apicid : 3 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save bogomips: 5223.61 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Also - with qemu-kvm and this AMD x4 620 I cannot use phenom nor host cpu. Core2duo works fine. On a core2duo (e8400/e8500) all cpu options are supported. -- 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: Slow PXE boot in qemu.git (fast in qemu-kvm.git)
On 04/08/2011 06:25 PM, Luiz Capitulino wrote: Hi there, Summary: - PXE boot in qemu.git (HEAD f124a41) is quite slow, more than 5 minutes. Got the problem with e1000, virtio and rtl8139. However, pcnet *works* (it's as fast as qemu-kvm.git) - PXE boot in qemu-kvm.git (HEAD df85c051) is fast, less than a minute. Tried with e1000, virtio and rtl8139 (I don't remember if I tried with pcnet) I tried with qemu.git v0.13.0 in order to check if this was a regression, but I got the same problem... Then I inspected qemu-kvm.git under the assumption that it could have a fix that wasn't commited to qemu.git. Found this: - commit 0836b77f0f65d56d08bdeffbac25cd6d78267dc9 which is merge, works - commit cc015e9a5dde2f03f123357fa060acbdfcd570a4 does not work (it's slow) I tried a bisect, but it brakes due to gcc4 vs. gcc3 changes. Then I inspected commits manually, and found out that commit 64d7e9a4 doesn't work, which makes me think that the fix could be in the conflict resolution of 0836b77f, which makes me remember that I'm late for diner, so my conclusions at this point are not reliable :) Can you run kvm_stat to see what the exit rates are? Maybe we're missing a coalesced io in qemu.git? It's also possible that gpxe is hitting the apic or pit quite a lot. Regards, Anthony Liguori Ideas? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: trace-cmd errors on kvm events
On 04/08/11 17:42, Jan Kiszka wrote: > What I also did is updating trace-cmd git and then reinstalling the > latest plugins: make install_plugins prefix=$HOME. They then end up in > $HOME/.trace-cmd/plugins. Now I do not have a single error message > anymore, including that file not found. Indeed. That did the trick. I was just running out of the build directory -- without doing an install of any kind. -- 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: trace-cmd errors on kvm events
On 2011-04-09 01:26, David Ahern wrote: > On 04/08/11 15:18, Jan Kiszka wrote: >> Let me check... indeed, I'm getting the same file-not-found here with >> trace-cmd.git 9cce1c9b5b when starting it directly from its build directory. >> >> But maybe your trace-cmd or kernel versions are too old / incompatible. >> I'm not getting complaints about unparseable events with the above >> snapshot and 2.6.38. > > 2.6.38.2 kernel, trace-cmd 3e8b5b8 which is March 18 (though git pull > done this morning). > > For grins I checked-out 9cce1c9b5b and same error: > trace-cmd record -e kvm -- sleep 1 > trace-cmd report 2>&1 | less > > You do have to put stderr onto stdout to see the messages I reported > earlier. Or look for [FAILED TO PARSE] on the kvm_exit and > kvm_emulate_insn lines. I did that. What I also did is updating trace-cmd git and then reinstalling the latest plugins: make install_plugins prefix=$HOME. They then end up in $HOME/.trace-cmd/plugins. Now I do not have a single error message anymore, including that file not found. Jan signature.asc Description: OpenPGP digital signature
Re: trace-cmd errors on kvm events
On 04/08/11 15:18, Jan Kiszka wrote: > Let me check... indeed, I'm getting the same file-not-found here with > trace-cmd.git 9cce1c9b5b when starting it directly from its build directory. > > But maybe your trace-cmd or kernel versions are too old / incompatible. > I'm not getting complaints about unparseable events with the above > snapshot and 2.6.38. 2.6.38.2 kernel, trace-cmd 3e8b5b8 which is March 18 (though git pull done this morning). For grins I checked-out 9cce1c9b5b and same error: trace-cmd record -e kvm -- sleep 1 trace-cmd report 2>&1 | less You do have to put stderr onto stdout to see the messages I reported earlier. Or look for [FAILED TO PARSE] on the kvm_exit and kvm_emulate_insn lines. David -- 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
Slow PXE boot in qemu.git (fast in qemu-kvm.git)
Hi there, Summary: - PXE boot in qemu.git (HEAD f124a41) is quite slow, more than 5 minutes. Got the problem with e1000, virtio and rtl8139. However, pcnet *works* (it's as fast as qemu-kvm.git) - PXE boot in qemu-kvm.git (HEAD df85c051) is fast, less than a minute. Tried with e1000, virtio and rtl8139 (I don't remember if I tried with pcnet) I tried with qemu.git v0.13.0 in order to check if this was a regression, but I got the same problem... Then I inspected qemu-kvm.git under the assumption that it could have a fix that wasn't commited to qemu.git. Found this: - commit 0836b77f0f65d56d08bdeffbac25cd6d78267dc9 which is merge, works - commit cc015e9a5dde2f03f123357fa060acbdfcd570a4 does not work (it's slow) I tried a bisect, but it brakes due to gcc4 vs. gcc3 changes. Then I inspected commits manually, and found out that commit 64d7e9a4 doesn't work, which makes me think that the fix could be in the conflict resolution of 0836b77f, which makes me remember that I'm late for diner, so my conclusions at this point are not reliable :) Ideas? -- 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: [ANNOUNCE] Native Linux KVM tool
On 04/08/2011 02:20 PM, Andrea Arcangeli wrote:
Hi Anthony,
On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
An example is ioport_ops. This maps directly to
ioport_{read,write}_table in QEMU. Then you use ioport__register() to
register entries in this table similar register_ioport_{read,write}() in
QEMU.
The use of a struct is a small improvement but the fundamental design is
flawed because it models a view of hardware where all devices are
directly connected to the CPU. This is not how hardware works at all.
Not sure if I've the whole picture on this but I see no answer to your
email and I found your remark above the most interesting. This is
because I thought the whole point of a native kvm tool was to go all
the paravirt way to provide max performance and maybe also depend on
vhost as much as possible.
Yeah, if that's the goal, skip all the mini-BIOS junk and just rely on a
PV kernel in the guest.
I think a mini userspace that assumes that we can change the guest
kernel and avoids having a ton of complexity to do things like CMOS
emulation would be a really interesting thing to do.
Regards,
Anthony Liguori
--
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: [ANNOUNCE] Native Linux KVM tool
On 04/08/2011 10:59 AM, Scott Wood wrote: On Thu, 7 Apr 2011 21:14:06 -0500 Anthony Liguori wrote: If someone was going to seriously go about doing something like this, a better approach would be to start with QEMU and remove anything non-x86 and all of the UI/command line/management bits and start there. There's nothing more I'd like to see than a viable alternative to QEMU but ignoring any of the architectural mistakes in QEMU and repeating them in a new project isn't going to get there. Supporting only a single architecture sounds like a significant architectural mistake... only x86 deserves clean code? No, you just have to start somewhere. Since x86 is probably the ugliest, I think it's the best place to start. Regards, Anthony Liguori -Scott -- 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: trace-cmd errors on kvm events
On 2011-04-08 23:12, David Ahern wrote:
>
>
> On 04/08/11 15:07, Jan Kiszka wrote:
>> On 2011-04-08 20:53, David Ahern wrote:
>>> 2.6.38.2 kernel with trace-cmd git pulled this morning:
>>>
>>> trace-cmd record -e kvm
>>>
>>> trace-cmd report 2>&1 | less
>>>
>>> trace-cmd: No such file or directory
>>
>> Does this error come from trace-cmd failing to find its kvm plugin?
>> Check what strace -e open says.
>>
>> Jan
>>
>
> Tried that before - it was not enlightening.
> strace -e trace=open trace-cmd report 2>&1 | less
>
> open("/etc/ld.so.cache", O_RDONLY) = 3
> open("/lib64/libdl.so.2", O_RDONLY) = 3
> open("/lib64/libc.so.6", O_RDONLY) = 3
> open("/root/trace.dat", O_RDONLY) = 3
> trace-cmd: No such file or directory
> function ftrace_print_symbols_seq not defined
> failed to read event print fmt for kvm_nested_vmexit_inject
> function ftrace_print_symbols_seq not defined
> failed to read event print fmt for kvm_nested_vmexit
> function ftrace_print_symbols_seq not defined
> failed to read event print fmt for kvm_exit
> bad op token {
> failed to read event print fmt for kvm_emulate_insn
> open("/proc/meminfo", O_RDONLY) = 4
Let me check... indeed, I'm getting the same file-not-found here with
trace-cmd.git 9cce1c9b5b when starting it directly from its build directory.
But maybe your trace-cmd or kernel versions are too old / incompatible.
I'm not getting complaints about unparseable events with the above
snapshot and 2.6.38.
Jan
signature.asc
Description: OpenPGP digital signature
Re: trace-cmd errors on kvm events
On 04/08/11 15:07, Jan Kiszka wrote:
> On 2011-04-08 20:53, David Ahern wrote:
>> 2.6.38.2 kernel with trace-cmd git pulled this morning:
>>
>> trace-cmd record -e kvm
>>
>> trace-cmd report 2>&1 | less
>>
>> trace-cmd: No such file or directory
>
> Does this error come from trace-cmd failing to find its kvm plugin?
> Check what strace -e open says.
>
> Jan
>
Tried that before - it was not enlightening.
strace -e trace=open trace-cmd report 2>&1 | less
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libdl.so.2", O_RDONLY) = 3
open("/lib64/libc.so.6", O_RDONLY) = 3
open("/root/trace.dat", O_RDONLY) = 3
trace-cmd: No such file or directory
function ftrace_print_symbols_seq not defined
failed to read event print fmt for kvm_nested_vmexit_inject
function ftrace_print_symbols_seq not defined
failed to read event print fmt for kvm_nested_vmexit
function ftrace_print_symbols_seq not defined
failed to read event print fmt for kvm_exit
bad op token {
failed to read event print fmt for kvm_emulate_insn
open("/proc/meminfo", O_RDONLY) = 4
David
--
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
buggy emulate_int_real
Hi, at https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090, it was found that emulate_int_real() sometimes pushes the wrong eip when doing a int. Whereas with non-kvm qemu we push the next instruction after the int, with kvm we push the addr of the instruction itself. I thought it'd be simple to fix (bump the value being pushed :), but my attempts at that have failed. Well, the right value seemed to get pushed, but kvm started to act rather funky. So I just removed commits a92601bb707f6f49fd5563ef3d09928e70cc222e KVM: VMX: Emulated real mode interrupt injection 63995653ade16deacaea5b49ceaf6376314593ac KVM: Add kvm_inject_realmode_interrupt() wrapper 6e154e56b4d7a6a28c54f0984e13d3f8defc4755 KVM: x86 emulator: Add into, int, and int3 instructions (opcodes 0xcc-0xce) and now it behaves as I'd expect. There were a few commits tweaking these functions, and I have not checked whether reverting some of those helps. Anyone happen to know what exactly is going on? thanks, -serge -- 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: trace-cmd errors on kvm events
On 2011-04-08 20:53, David Ahern wrote: > 2.6.38.2 kernel with trace-cmd git pulled this morning: > > trace-cmd record -e kvm > > trace-cmd report 2>&1 | less > > trace-cmd: No such file or directory Does this error come from trace-cmd failing to find its kvm plugin? Check what strace -e open says. Jan signature.asc Description: OpenPGP digital signature
Re: trace-cmd errors on kvm events
On 04/08/11 14:50, Stefan Hajnoczi wrote:
> On Fri, Apr 8, 2011 at 7:53 PM, David Ahern wrote:
>> 2.6.38.2 kernel with trace-cmd git pulled this morning:
>>
>> trace-cmd record -e kvm
>>
>> trace-cmd report 2>&1 | less
>>
>> trace-cmd: No such file or directory
>> function ftrace_print_symbols_seq not defined
>> failed to read event print fmt for kvm_nested_vmexit_inject
>> function ftrace_print_symbols_seq not defined
>> failed to read event print fmt for kvm_nested_vmexit
>> function ftrace_print_symbols_seq not defined
>> failed to read event print fmt for kvm_exit
>> bad op token {
>> failed to read event print fmt for kvm_emulate_insn
>>
>>qemu-kvm-1864 [002] 2253.714134: kvm_entry:vcpu 1
>>qemu-kvm-1863 [008] 2253.714136: kvm_exit: [FAILED
>> TO PARSE] exit_reason=44 guest_rip=0xc01185ed isa=1 info1=4272 info2=0
>>qemu-kvm-1864 [002] 2253.714138: kvm_exit: [FAILED
>> TO PARSE] exit_reason=44 guest_rip=0xc01185ed isa=1 info1=4272 info2=0
>>qemu-kvm-1863 [008] 2253.714145: kvm_emulate_insn: [FAILED
>> TO PARSE] rip=3222373869 csbase=0 len=2 insn=<89>^H]<8B>^U<95>KU
>> <89>]<8D>^E flags=5 failed=0
>>
>> I have not used trace-cmd much, so I am not familiar with the code. Is
>> this a known issue? Suggestions on how to debug?
>
> I think there have been issues for a long time. I've never gotten
> perf or trace-cmd to be happy with kvm:* events. Here is a related
> thread from a while back:
>
> https://lkml.org/lkml/2010/5/26/194
>
> When I looked a while back the problem was due to how there is some
> preprocessor magic in Linux that ends up exporting C expressions as
> strings to userspace and neither perf nor trace-cmd have the parsing
> smarts to evaluate the C expressions at runtime.
Hmm.. ok. I thought it had been added - to trace-cmd at least. And I
recall Avi recently sending a patch to trace-cmd folks - I took that to
mean it works. Evidently, not.
David
>
> I ended up using ftrace instead which handles everything inside the
> kernel and compiles in those C expressions.
>
> Stefan
--
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: trace-cmd errors on kvm events
On Fri, Apr 8, 2011 at 7:53 PM, David Ahern wrote:
> 2.6.38.2 kernel with trace-cmd git pulled this morning:
>
> trace-cmd record -e kvm
>
> trace-cmd report 2>&1 | less
>
> trace-cmd: No such file or directory
> function ftrace_print_symbols_seq not defined
> failed to read event print fmt for kvm_nested_vmexit_inject
> function ftrace_print_symbols_seq not defined
> failed to read event print fmt for kvm_nested_vmexit
> function ftrace_print_symbols_seq not defined
> failed to read event print fmt for kvm_exit
> bad op token {
> failed to read event print fmt for kvm_emulate_insn
>
> qemu-kvm-1864 [002] 2253.714134: kvm_entry: vcpu 1
> qemu-kvm-1863 [008] 2253.714136: kvm_exit: [FAILED
> TO PARSE] exit_reason=44 guest_rip=0xc01185ed isa=1 info1=4272 info2=0
> qemu-kvm-1864 [002] 2253.714138: kvm_exit: [FAILED
> TO PARSE] exit_reason=44 guest_rip=0xc01185ed isa=1 info1=4272 info2=0
> qemu-kvm-1863 [008] 2253.714145: kvm_emulate_insn: [FAILED
> TO PARSE] rip=3222373869 csbase=0 len=2 insn=<89>^H]<8B>^U<95>KU
> <89>]<8D>^E flags=5 failed=0
>
> I have not used trace-cmd much, so I am not familiar with the code. Is
> this a known issue? Suggestions on how to debug?
I think there have been issues for a long time. I've never gotten
perf or trace-cmd to be happy with kvm:* events. Here is a related
thread from a while back:
https://lkml.org/lkml/2010/5/26/194
When I looked a while back the problem was due to how there is some
preprocessor magic in Linux that ends up exporting C expressions as
strings to userspace and neither perf nor trace-cmd have the parsing
smarts to evaluate the C expressions at runtime.
I ended up using ftrace instead which handles everything inside the
kernel and compiles in those C expressions.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] KVM test: enospc subtest: Catch error.TestWarn in main loop
Now that image_check() can throw TestWarn exceptions, let's
catch it as well.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/tests/enospc.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/tests/enospc.py b/client/tests/kvm/tests/enospc.py
index 3c53b64..9917144 100644
--- a/client/tests/kvm/tests/enospc.py
+++ b/client/tests/kvm/tests/enospc.py
@@ -54,7 +54,7 @@ def run_enospc(test, params, env):
image_params = vm.params.object_params(image_name)
try:
kvm_vm.check_image(image_params, test.bindir)
-except kvm_vm.VMError, e:
+except (kvm_vm.VMError, error.TestWarn), e:
logging.error(e)
logging.info("Guest paused, extending Logical Volume size")
try:
--
1.7.4.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] KVM test: Check for guest kernel crash after migration
We noticed some times guests crash after migration. Putting a kernel crash check on that stage makes it easier to indentify when such conditions happened. Signed-off-by: Lucas Meneghel Rodrigues --- client/tests/kvm/kvm_vm.py |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py index f004f4f..f0b8152 100755 --- a/client/tests/kvm/kvm_vm.py +++ b/client/tests/kvm/kvm_vm.py @@ -1678,6 +1678,7 @@ class VM: if local: time.sleep(1) self.verify_alive() +self.verify_kernel_crash() if local and stable_check: try: -- 1.7.4.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] KVM test: Unattended install - Fix incorrect verify_kernel_crash
The idea was to put the kernel crash verification during
the install loop, not at the beginning of the test.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/tests/unattended_install.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/tests/unattended_install.py
b/client/tests/kvm/tests/unattended_install.py
index 4868053..955f8d6 100644
--- a/client/tests/kvm/tests/unattended_install.py
+++ b/client/tests/kvm/tests/unattended_install.py
@@ -16,7 +16,6 @@ def run_unattended_install(test, params, env):
"""
vm = env.get_vm(params["main_vm"])
vm.verify_alive()
-vm.verify_kernel_crash()
install_timeout = int(params.get("timeout", 3000))
post_install_delay = int(params.get("post_install_delay", 0))
@@ -34,6 +33,7 @@ def run_unattended_install(test, params, env):
start_time = time.time()
while (time.time() - start_time) < install_timeout:
vm.verify_alive()
+vm.verify_kernel_crash()
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
client.connect((vm.get_address(), port))
--
1.7.4.2
--
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: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Fri, Apr 8, 2011 at 10:32 PM, Anthony Liguori wrote:
> On 04/08/2011 02:17 PM, Blue Swirl wrote:
>>
>> On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov wrote:
>>>
>>> On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
On 04/07/2011 02:17 PM, Gleb Natapov wrote:
>
> On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
>>
>> On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov
>> wrote:
>>
>> I'd prefer something more generic like these:
>> raise /apic@fee0:l1int
>> lower /i44FX-pcihost/e1000@03.0/pinD
>>
>> The clumsier syntax shouldn't be a problem, since this would be a
>> system developer tool.
>>
>> Some kind of IRQ registration would be needed for this to work without
>> lots of changes.
>
> True. The ability to trigger any interrupt line is very useful for
> debugging. I often re-implement it during debug.
And it's a good thing to have, but exposing this as the only API to
do something as simple as generating a guest crash dump is not the
friendliest thing in the world to do to users.
>>> Well, this is not intended to be used by regular users directly and
>>> management can provide nicer interface for issuing NMI. But really,
>>> my point is that NMI actually generates guest core dump in such rare
>>> cases (only preconfigured Windows guests) that it doesn't warrant to
>>> name command as such. Management is in much better position to implement
>>> functionality with such name since it knows what type of guest it runs
>>> and can tell agent to configure guest accordingly.
>>
>> Does the management need to know about each and every debugging
>> oriented interface? For example, "info regs", "info mem", "info irq"
>> and tracepoints?
>>
>> I think giving IRQs symbolic names could solve some other problems as
>> well. Maybe it should be possible to connect IRQs in a configuration
>> file and even with command line:
>> -device port90,irqid=p90out -device pckbd,irqid=kbdout -device
>> and,in=p90out,in=kbdout,out=sreset device system_reset,in=sreset
>
> You really want devices to have properties and for the device properties to
> be discoverable. For instance:
>
> struct DeviceInfo
> {
> .name = "and",
> .properties = {
> DEFINE_IRQ_IN(AndDevice, in[0]),
> DEFINE_IRQ_IN(AndDevice, in[1]),
> DEFINE_IRQ_OUT(AndDevice, out),
> },
> };
>
> And then you can do:
>
> -device port90,id=port90 -device pckbd,id=pckbd \
> -device and,in[0]=port90.out,in[1]=pckbd.out,id=reset_and \
> -device system_reset.in=reset_and
Exactly. Given a NAND device, we could construct entire machines from
CLI or for example co-simulate SoCs with FPGAs using cells based on
the net lists.
--
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: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 04/08/2011 02:17 PM, Blue Swirl wrote:
On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov wrote:
On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
On 04/07/2011 02:17 PM, Gleb Natapov wrote:
On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapovwrote:
I'd prefer something more generic like these:
raise /apic@fee0:l1int
lower /i44FX-pcihost/e1000@03.0/pinD
The clumsier syntax shouldn't be a problem, since this would be a
system developer tool.
Some kind of IRQ registration would be needed for this to work without
lots of changes.
True. The ability to trigger any interrupt line is very useful for
debugging. I often re-implement it during debug.
And it's a good thing to have, but exposing this as the only API to
do something as simple as generating a guest crash dump is not the
friendliest thing in the world to do to users.
Well, this is not intended to be used by regular users directly and
management can provide nicer interface for issuing NMI. But really,
my point is that NMI actually generates guest core dump in such rare
cases (only preconfigured Windows guests) that it doesn't warrant to
name command as such. Management is in much better position to implement
functionality with such name since it knows what type of guest it runs
and can tell agent to configure guest accordingly.
Does the management need to know about each and every debugging
oriented interface? For example, "info regs", "info mem", "info irq"
and tracepoints?
I think giving IRQs symbolic names could solve some other problems as
well. Maybe it should be possible to connect IRQs in a configuration
file and even with command line:
-device port90,irqid=p90out -device pckbd,irqid=kbdout -device
and,in=p90out,in=kbdout,out=sreset device system_reset,in=sreset
You really want devices to have properties and for the device properties
to be discoverable. For instance:
struct DeviceInfo
{
.name = "and",
.properties = {
DEFINE_IRQ_IN(AndDevice, in[0]),
DEFINE_IRQ_IN(AndDevice, in[1]),
DEFINE_IRQ_OUT(AndDevice, out),
},
};
And then you can do:
-device port90,id=port90 -device pckbd,id=pckbd \
-device and,in[0]=port90.out,in[1]=pckbd.out,id=reset_and \
-device system_reset.in=reset_and
Regards,
Anthony Liguori
or
-device
and,in=/i44FX-pcihost/PIIX3/i8042/out1,in=/i44FX-pcihost/PIIX3/p90/out1,out=/QEMU/system_reset
--
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: [ANNOUNCE] Native Linux KVM tool
Hi Anthony,
On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
> An example is ioport_ops. This maps directly to
> ioport_{read,write}_table in QEMU. Then you use ioport__register() to
> register entries in this table similar register_ioport_{read,write}() in
> QEMU.
>
> The use of a struct is a small improvement but the fundamental design is
> flawed because it models a view of hardware where all devices are
> directly connected to the CPU. This is not how hardware works at all.
Not sure if I've the whole picture on this but I see no answer to your
email and I found your remark above the most interesting. This is
because I thought the whole point of a native kvm tool was to go all
the paravirt way to provide max performance and maybe also depend on
vhost as much as possible.
I mean if we have to care to emulate hardware _again_ and end up
replicating qemu (with the only exception of TCG) I don't see an need
of an alternative userland, let's not understimate how qemu is already
mature and good to emulate real hardware. I thought the whole point
was to exactly avoid any complaint like "this is not how the hardware
works" and focus only to optimize for smp and max scalability and
ignore how a real hardware would actually work to get there faster
than qemu can.
I had no time to read/try it yet I'm just reading the thread here...
Thanks,
Andrea
--
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: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov wrote: > On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote: >> On 04/07/2011 02:17 PM, Gleb Natapov wrote: >> >On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote: >> >>On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov wrote: >> >> >> >>I'd prefer something more generic like these: >> >>raise /apic@fee0:l1int >> >>lower /i44FX-pcihost/e1000@03.0/pinD >> >> >> >>The clumsier syntax shouldn't be a problem, since this would be a >> >>system developer tool. >> >> >> >>Some kind of IRQ registration would be needed for this to work without >> >>lots of changes. >> >True. The ability to trigger any interrupt line is very useful for >> >debugging. I often re-implement it during debug. >> >> And it's a good thing to have, but exposing this as the only API to >> do something as simple as generating a guest crash dump is not the >> friendliest thing in the world to do to users. >> > Well, this is not intended to be used by regular users directly and > management can provide nicer interface for issuing NMI. But really, > my point is that NMI actually generates guest core dump in such rare > cases (only preconfigured Windows guests) that it doesn't warrant to > name command as such. Management is in much better position to implement > functionality with such name since it knows what type of guest it runs > and can tell agent to configure guest accordingly. Does the management need to know about each and every debugging oriented interface? For example, "info regs", "info mem", "info irq" and tracepoints? I think giving IRQs symbolic names could solve some other problems as well. Maybe it should be possible to connect IRQs in a configuration file and even with command line: -device port90,irqid=p90out -device pckbd,irqid=kbdout -device and,in=p90out,in=kbdout,out=sreset device system_reset,in=sreset or -device and,in=/i44FX-pcihost/PIIX3/i8042/out1,in=/i44FX-pcihost/PIIX3/p90/out1,out=/QEMU/system_reset -- 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: [Qemu-devel] KVM call minutes for Apr 5
On Fri, Apr 08, 2011 at 09:58:22AM -0300, Lucas Meneghel Rodrigues wrote: > On Thu, 2011-04-07 at 11:03 +0100, Stefan Hajnoczi wrote: > > On Tue, Apr 5, 2011 at 6:37 PM, Lucas Meneghel Rodrigues > > wrote: > > >> Perhaps kvm-autotest is a good platform for the automated testing of > > >> ARM TCG. Paul is CCed, I recently saw the Jenkins qemu build and boot > > >> tests he has set up. Lucas, do you have ideas on how these efforts > > >> can work together to bring testing to upstream QEMU? > > >> http://validation.linaro.org/jenkins/job/qemu-boot-images/ > > > > > > I heard about jenkins before and it is indeed a nice project. What they > > > do here, from what I could assess browsing at the webpage you provided > > > is: > > > > > > 1) Build qemu.git every time there are commits > > > 2) Boot pre-made 'pristine' images, one is a lenny arm image and the > > > other is a linaro arm image. > > > > > > It is possible to do the same with kvm autotest, just a matter of not > > > performing guest install tests and executing only the boot tests with > > > pre-made images. What jenkins does here is a even quicker and shorter > > > version of our sanity jobs. > > > > > > About how we can work together, I thought about some possibilities: > > > > > > 1) Modify the jenkins test step to execute a kvm autotest job after the > > > build, with the stripped down test set. We might gain some extra debug > > > info, that the current test step does not seem to provide > > > 2) Do the normal test step and if that succeeds, trigger a kvm autotest > > > job that does more comprehensive testing, such as migration, time drift, > > > block layer, etc > > > > > > The funny thing is that KVM autotest has infrastructure to do the same > > > as jenkins does, but jenkins is highly streamlined for the buildbot use > > > case (continuous build and integration), and I see that as a very nice > > > advantage. So I'd rather keep use jenkins and have kvm autotest plugged > > > into it conveniently. > > > > That sounds good. I think the benefit of working together is that > > different entities (Linaro, Red Hat, etc) can contribute QEMU tests > > into a single place. That testing can then cover to both upstream and > > downstream to prevent breakage. > > > > So kvm-autotest can run in single job mode and kicked off from jenkins > > or buildbot? > > > > It sounds like kvm-autotest has or needs its own cron, result > > archiving, etc infrastructure. Does it make sense to use a harness > > like jenkins or buildbot instead and focus kvm-autotest purely as a > > testing framework? > > In the context that there are already jenkins/buildbot servers running > for qemu, having only the KVM testing part (autotest client + kvm test) > is a possibility, to make things easier to plug and work with what is > already deployed. > > However, not possible to focus KVM autotest as a 'test framework'. What > we call KVM autotest is in actuality, a client test of autotest. > Autotest is a generic, large collection of programs and libraries > targeted at peforming automated testing on the linux platform, it was > developed to test the linux kernel itself, and it is used to do > precisely that. Look at test.kernel.org. All those tests are executed by > autotest. > > So, autotest is much more than KVM testing, and I am one of the autotest > maintainers, so I am commited to work on all parts of that stack. > Several testing projects urelated to KVM use our code, and our > harnessing and infrastructure is already pretty good, we'll keep to > develop it. > > The whole thing was designed in a modular way, so it's doable to use > parts of it (such as the autotest client and the KVM test) and integrate > with stuff such as jenkins and buildbot, and if people need and want to > do that, awesome. But we are going to continue develop autotest as a > whole framework/automation utilities/API, while developing the KVM test. I wasn't aware of the scope of autotest and your involvement. I need to look into autotest more :). Stefan -- 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
trace-cmd errors on kvm events
2.6.38.2 kernel with trace-cmd git pulled this morning:
trace-cmd record -e kvm
trace-cmd report 2>&1 | less
trace-cmd: No such file or directory
function ftrace_print_symbols_seq not defined
failed to read event print fmt for kvm_nested_vmexit_inject
function ftrace_print_symbols_seq not defined
failed to read event print fmt for kvm_nested_vmexit
function ftrace_print_symbols_seq not defined
failed to read event print fmt for kvm_exit
bad op token {
failed to read event print fmt for kvm_emulate_insn
qemu-kvm-1864 [002] 2253.714134: kvm_entry:vcpu 1
qemu-kvm-1863 [008] 2253.714136: kvm_exit: [FAILED
TO PARSE] exit_reason=44 guest_rip=0xc01185ed isa=1 info1=4272 info2=0
qemu-kvm-1864 [002] 2253.714138: kvm_exit: [FAILED
TO PARSE] exit_reason=44 guest_rip=0xc01185ed isa=1 info1=4272 info2=0
qemu-kvm-1863 [008] 2253.714145: kvm_emulate_insn: [FAILED
TO PARSE] rip=3222373869 csbase=0 len=2 insn=<89>^H]<8B>^U<95>KU
<89>]<8D>^E flags=5 failed=0
I have not used trace-cmd much, so I am not familiar with the code. Is
this a known issue? Suggestions on how to debug?
Thanks,
David
--
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 v2 1/2] rbd: use the higher level librbd instead of just librados
On 04/08/2011 01:43 AM, Stefan Hajnoczi wrote: On Mon, Mar 28, 2011 at 04:15:57PM -0700, Josh Durgin wrote: librbd stacks on top of librados to provide access to rbd images. Using librbd simplifies the qemu code, and allows qemu to use new versions of the rbd format with few (if any) changes. Signed-off-by: Josh Durgin Signed-off-by: Yehuda Sadeh --- block/rbd.c | 785 +++-- block/rbd_types.h | 71 - configure | 33 +-- 3 files changed, 221 insertions(+), 668 deletions(-) delete mode 100644 block/rbd_types.h Hi Josh, I have applied your patches onto qemu.git/master and am running ceph.git/master. Unfortunately qemu-iotests fails for me. Thanks for testing and the detailed instructions! I'm looking into this now. Josh Durgin -- 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 v2 1/2] rbd: use the higher level librbd instead of just librados
On Fri, Apr 8, 2011 at 9:43 AM, Stefan Hajnoczi wrote: > On Mon, Mar 28, 2011 at 04:15:57PM -0700, Josh Durgin wrote: >> librbd stacks on top of librados to provide access >> to rbd images. >> >> Using librbd simplifies the qemu code, and allows >> qemu to use new versions of the rbd format >> with few (if any) changes. >> >> Signed-off-by: Josh Durgin >> Signed-off-by: Yehuda Sadeh >> --- >> block/rbd.c | 785 >> +++-- >> block/rbd_types.h | 71 - >> configure | 33 +-- >> 3 files changed, 221 insertions(+), 668 deletions(-) >> delete mode 100644 block/rbd_types.h > > Hi Josh, > I have applied your patches onto qemu.git/master and am running > ceph.git/master. > > Unfortunately qemu-iotests fails for me. I forgot to mention that qemu-iotests lives at: git://git.kernel.org/pub/scm/linux/kernel/git/hch/qemu-iotests.git Stefan -- 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 v2 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
On 2011-04-08 18:08, Glauber Costa wrote: > On Fri, 2011-04-08 at 17:54 +0200, Jan Kiszka wrote: >>> +} >> >> Did I miss some change in the plan? I thought we were heading for a >> generic, reusable driftfix tool box (or periodic timer service)? Or is >> this intentionally an intermediate step? > > Which is a medium to long way in the future. There is benefit of having > this early, since it can deliver real functionality - a reliable hpet, > and converting to whatever the api may look like in the future. > Well, if the PIT and the RTC should use it as well, which is probably rather a short term goal, we already have two more users. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] kvm tools: introduces virtio.c and virtio.h
all virito core code should be in virtio.c
Signed-off-by: Asias He
---
tools/kvm/Makefile|1 +
tools/kvm/blk-virtio.c|2 +-
tools/kvm/console-virtio.c|2 +-
tools/kvm/include/kvm/virtio.h| 44 ++
tools/kvm/include/kvm/virtqueue.h | 73 -
tools/kvm/virtio.c| 39
6 files changed, 86 insertions(+), 75 deletions(-)
create mode 100644 tools/kvm/include/kvm/virtio.h
delete mode 100644 tools/kvm/include/kvm/virtqueue.h
create mode 100644 tools/kvm/virtio.c
diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 55f342d..82d41b6 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -26,6 +26,7 @@ OBJS += mmio.o
OBJS += pci.o
OBJS += util.o
OBJS += term.o
+OBJS += virtio.o
DEPS := $(patsubst %.o,%.d,$(OBJS))
diff --git a/tools/kvm/blk-virtio.c b/tools/kvm/blk-virtio.c
index e94d7b3..2eb9734 100644
--- a/tools/kvm/blk-virtio.c
+++ b/tools/kvm/blk-virtio.c
@@ -3,7 +3,7 @@
#include "kvm/virtio_pci.h"
#include "kvm/disk-image.h"
-#include "kvm/virtqueue.h"
+#include "kvm/virtio.h"
#include "kvm/ioport.h"
#include "kvm/util.h"
#include "kvm/kvm.h"
diff --git a/tools/kvm/console-virtio.c b/tools/kvm/console-virtio.c
index f094610..3926536 100644
--- a/tools/kvm/console-virtio.c
+++ b/tools/kvm/console-virtio.c
@@ -1,7 +1,7 @@
#include "kvm/console-virtio.h"
#include "kvm/virtio_pci.h"
#include "kvm/disk-image.h"
-#include "kvm/virtqueue.h"
+#include "kvm/virtio.h"
#include "kvm/ioport.h"
#include "kvm/util.h"
#include "kvm/term.h"
diff --git a/tools/kvm/include/kvm/virtio.h b/tools/kvm/include/kvm/virtio.h
new file mode 100644
index 000..075387d
--- /dev/null
+++ b/tools/kvm/include/kvm/virtio.h
@@ -0,0 +1,44 @@
+#ifndef KVM__VIRTIO_H
+#define KVM__VIRTIO_H
+
+#include
+
+#include
+#include
+
+#include "kvm/kvm.h"
+
+struct virt_queue {
+ struct vringvring;
+ uint32_tpfn;
+ /* The last_avail_idx field is an index to ->ring of struct vring_avail.
+ It's where we assume the next request index is at. */
+ uint16_tlast_avail_idx;
+};
+
+static inline uint16_t virt_queue__pop(struct virt_queue *queue)
+{
+ return queue->vring.avail->ring[queue->last_avail_idx++ %
queue->vring.num];
+}
+
+static inline struct vring_desc *virt_queue__get_desc(struct virt_queue
*queue, uint16_t desc_ndx)
+{
+ return &queue->vring.desc[desc_ndx];
+}
+
+static inline struct vring_used_elem *virt_queue__get_used_elem(struct
virt_queue *queue)
+{
+ return &queue->vring.used->ring[queue->vring.used->idx++ %
queue->vring.num];
+}
+
+
+static inline bool virt_queue__available(struct virt_queue *vq)
+{
+ return vq->vring.avail->idx != vq->last_avail_idx;
+}
+
+struct vring_used_elem *virt_queue__set_used_elem(struct virt_queue *queue,
uint32_t head, uint32_t len);
+
+uint16_t virt_queue__get_iov(struct virt_queue *queue, struct iovec iov[],
uint16_t *out, uint16_t *in, struct kvm *kvm);
+
+#endif /* KVM__VIRTIO_H */
diff --git a/tools/kvm/include/kvm/virtqueue.h
b/tools/kvm/include/kvm/virtqueue.h
deleted file mode 100644
index de360ae..000
--- a/tools/kvm/include/kvm/virtqueue.h
+++ /dev/null
@@ -1,73 +0,0 @@
-#ifndef KVM__VIRTQUEUE_H
-#define KVM__VIRTQUEUE_H
-
-#include
-
-#include
-#include
-
-#include "kvm/kvm.h"
-
-struct virt_queue {
- struct vringvring;
- uint32_tpfn;
- /* The last_avail_idx field is an index to ->ring of struct vring_avail.
- It's where we assume the next request index is at. */
- uint16_tlast_avail_idx;
-};
-
-static inline uint16_t virt_queue__pop(struct virt_queue *queue)
-{
- return queue->vring.avail->ring[queue->last_avail_idx++ %
queue->vring.num];
-}
-
-static inline struct vring_desc *virt_queue__get_desc(struct virt_queue
*queue, uint16_t desc_ndx)
-{
- return &queue->vring.desc[desc_ndx];
-}
-
-static inline struct vring_used_elem *virt_queue__get_used_elem(struct
virt_queue *queue)
-{
- return &queue->vring.used->ring[queue->vring.used->idx++ %
queue->vring.num];
-}
-
-static inline struct vring_used_elem *virt_queue__set_used_elem(struct
virt_queue *queue, uint32_t head, uint32_t len)
-{
- struct vring_used_elem *used_elem;
- used_elem = &queue->vring.used->ring[queue->vring.used->idx++ %
queue->vring.num];
- used_elem->id = head;
- used_elem->len = len;
- return used_elem;
-}
-
-static inline bool virt_queue__available(struct virt_queue *vq)
-{
- return vq->vring.avail->idx != vq->last_avail_idx;
-}
-
-static inline uint16_t virt_queue__get_iov(struct virt_queue *queue, struct
iovec iov[], uint16_t *out, uint16_t *in, struct kvm *kvm)
-{
- struct vring_desc *desc;
- uint16_t head, idx;
-
-
[PATCH 5/5] kvm tools: use virt_queue__get_iov to simpify virtio blk io handle logic
This really makes my life much easier!
Signed-off-by: Asias He
---
tools/kvm/virtio-blk.c | 109 ++-
1 files changed, 33 insertions(+), 76 deletions(-)
diff --git a/tools/kvm/virtio-blk.c b/tools/kvm/virtio-blk.c
index 8351e7a..34eb3f7 100644
--- a/tools/kvm/virtio-blk.c
+++ b/tools/kvm/virtio-blk.c
@@ -30,7 +30,7 @@ struct blk_device {
/* virtio queue */
uint16_tqueue_selector;
- struct virt_queue virt_queues[NUM_VIRT_QUEUES];
+ struct virt_queue vqs[NUM_VIRT_QUEUES];
};
#define DISK_SEG_MAX 126
@@ -73,7 +73,7 @@ static bool virtio_blk_pci_io_in(struct kvm *self, uint16_t
port, void *data, in
case VIRTIO_PCI_GUEST_FEATURES:
return false;
case VIRTIO_PCI_QUEUE_PFN:
- ioport__write32(data,
blk_device.virt_queues[blk_device.queue_selector].pfn);
+ ioport__write32(data,
blk_device.vqs[blk_device.queue_selector].pfn);
break;
case VIRTIO_PCI_QUEUE_NUM:
ioport__write16(data, VIRTIO_BLK_QUEUE_SIZE);
@@ -98,66 +98,29 @@ static bool virtio_blk_pci_io_in(struct kvm *self, uint16_t
port, void *data, in
return true;
}
-static bool virtio_blk_request(struct kvm *self, struct virt_queue *queue)
+static bool virtio_blk_do_io_request(struct kvm *self, struct virt_queue
*queue)
{
+
+ struct iovec iov[VIRTIO_BLK_QUEUE_SIZE];
struct virtio_blk_outhdr *req;
- uint16_t desc_block_last;
- struct vring_desc *desc;
- uint16_t desc_status;
- uint16_t desc_block;
- uint32_t block_len;
- uint32_t block_cnt;
- uint16_t desc_hdr;
+ uint32_t block_len, block_cnt;
+ uint16_t out, in, head;
+ int err,err_cnt, i;
uint8_t *status;
void *block;
- int err;
- int err_cnt;
-
- /* header */
- desc_hdr= virt_queue__pop(queue);
-
- if (desc_hdr >= queue->vring.num) {
- warning("fatal I/O error");
- return false;
- }
- desc= virt_queue__get_desc(queue, desc_hdr);
- assert(!(desc->flags & VRING_DESC_F_INDIRECT));
+ head= virt_queue__get_iov(queue, iov, &out, &in, self);
- req = guest_flat_to_host(self, desc->addr);
-
- /* status */
- desc_status = desc_hdr;
-
- do {
- desc_block_last = desc_status;
- desc_status = virt_queue__get_desc(queue,
desc_status)->next;
-
- if (desc_status >= queue->vring.num) {
- warning("fatal I/O error");
- return false;
- }
-
- desc= virt_queue__get_desc(queue, desc_status);
- assert(!(desc->flags & VRING_DESC_F_INDIRECT));
-
- } while (desc->flags & VRING_DESC_F_NEXT);
-
- status = guest_flat_to_host(self, desc->addr);
+ /* head */
+ req = iov[0].iov_base;
/* block */
- desc_block = desc_hdr;
- block_cnt = 0;
- err_cnt = 0;
+ block_cnt = 0;
+ err_cnt = 0;
- do {
- desc_block = virt_queue__get_desc(queue, desc_block)->next;
-
- desc= virt_queue__get_desc(queue, desc_block);
- assert(!(desc->flags & VRING_DESC_F_INDIRECT));
-
- block = guest_flat_to_host(self, desc->addr);
- block_len = desc->len;
+ for (i = 1; i < out + in - 1; i++) {
+ block = iov[i].iov_base;
+ block_len = iov[i].iov_len;
switch (req->type) {
case VIRTIO_BLK_T_IN:
@@ -176,24 +139,28 @@ static bool virtio_blk_request(struct kvm *self, struct
virt_queue *queue)
req->sector += block_len >> SECTOR_SHIFT;
block_cnt += block_len;
+ }
- if (desc_block == desc_block_last)
- break;
-
- if (desc_block >= queue->vring.num) {
- warning("fatal I/O error");
- return false;
- }
-
- } while (true);
-
+ /* status */
+ status = iov[out + in - 1].iov_base;
*status = err_cnt ? VIRTIO_BLK_S_IOERR :
VIRTIO_BLK_S_OK;
- virt_queue__set_used_elem(queue, desc_hdr, block_cnt);
+ virt_queue__set_used_elem(queue, head, block_cnt);
return true;
}
+static void virtio_blk_handle_callback(struct kvm *self, uint16_t queue_index)
+{
+ struct virt_queue *vq;
+
+ vq = &blk_device.vqs[queue_index];
+ while (virt_queue__available(vq)) {
+ virtio_blk_do_io_request(self, vq);
+ }
+ kvm__irq_line(self,
[PATCH 4/5] kvm tools: drop virt_queue__get_used_elem virtio helper
Use virt_queue__set_used_elem insted.
Signed-off-by: Asias He
---
tools/kvm/include/kvm/virtio.h |6 --
tools/kvm/virtio-blk.c |5 +
2 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/tools/kvm/include/kvm/virtio.h b/tools/kvm/include/kvm/virtio.h
index 075387d..9f892a1 100644
--- a/tools/kvm/include/kvm/virtio.h
+++ b/tools/kvm/include/kvm/virtio.h
@@ -26,12 +26,6 @@ static inline struct vring_desc *virt_queue__get_desc(struct
virt_queue *queue,
return &queue->vring.desc[desc_ndx];
}
-static inline struct vring_used_elem *virt_queue__get_used_elem(struct
virt_queue *queue)
-{
- return &queue->vring.used->ring[queue->vring.used->idx++ %
queue->vring.num];
-}
-
-
static inline bool virt_queue__available(struct virt_queue *vq)
{
return vq->vring.avail->idx != vq->last_avail_idx;
diff --git a/tools/kvm/virtio-blk.c b/tools/kvm/virtio-blk.c
index a41d5ac..8351e7a 100644
--- a/tools/kvm/virtio-blk.c
+++ b/tools/kvm/virtio-blk.c
@@ -100,7 +100,6 @@ static bool virtio_blk_pci_io_in(struct kvm *self, uint16_t
port, void *data, in
static bool virtio_blk_request(struct kvm *self, struct virt_queue *queue)
{
- struct vring_used_elem *used_elem;
struct virtio_blk_outhdr *req;
uint16_t desc_block_last;
struct vring_desc *desc;
@@ -190,9 +189,7 @@ static bool virtio_blk_request(struct kvm *self, struct
virt_queue *queue)
*status = err_cnt ? VIRTIO_BLK_S_IOERR :
VIRTIO_BLK_S_OK;
- used_elem = virt_queue__get_used_elem(queue);
- used_elem->id = desc_hdr;
- used_elem->len = block_cnt;
+ virt_queue__set_used_elem(queue, desc_hdr, block_cnt);
return true;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] kvm tools: this patch unifies the name conventions to virtio-xxx
- rename {blk,console}-virtio.* to virtio-{blk,console}.*
- change the virtio block device PCI io space operation callback names
Signed-off-by: Asias He
---
tools/kvm/Makefile |4 +-
tools/kvm/blk-virtio.c | 293
tools/kvm/console-virtio.c | 218
tools/kvm/include/kvm/blk-virtio.h |8 -
tools/kvm/include/kvm/console-virtio.h |9 -
tools/kvm/include/kvm/virtio-blk.h |8 +
tools/kvm/include/kvm/virtio-console.h |9 +
tools/kvm/include/kvm/virtio-pci.h | 59 +++
tools/kvm/include/kvm/virtio_pci.h | 59 ---
tools/kvm/main.c |6 +-
tools/kvm/virtio-blk.c | 293
tools/kvm/virtio-console.c | 218
12 files changed, 592 insertions(+), 592 deletions(-)
delete mode 100644 tools/kvm/blk-virtio.c
delete mode 100644 tools/kvm/console-virtio.c
delete mode 100644 tools/kvm/include/kvm/blk-virtio.h
delete mode 100644 tools/kvm/include/kvm/console-virtio.h
create mode 100644 tools/kvm/include/kvm/virtio-blk.h
create mode 100644 tools/kvm/include/kvm/virtio-console.h
create mode 100644 tools/kvm/include/kvm/virtio-pci.h
delete mode 100644 tools/kvm/include/kvm/virtio_pci.h
create mode 100644 tools/kvm/virtio-blk.c
create mode 100644 tools/kvm/virtio-console.c
diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 82d41b6..45498a2 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -13,8 +13,8 @@ CSCOPE = cscope
TAGS = ctags
OBJS += 8250-serial.o
-OBJS += blk-virtio.o
-OBJS += console-virtio.o
+OBJS += virtio-blk.o
+OBJS += virtio-console.o
OBJS += cpuid.o
OBJS += read-write.o
OBJS += disk-image.o
diff --git a/tools/kvm/blk-virtio.c b/tools/kvm/blk-virtio.c
deleted file mode 100644
index 2eb9734..000
--- a/tools/kvm/blk-virtio.c
+++ /dev/null
@@ -1,293 +0,0 @@
-#include "kvm/blk-virtio.h"
-
-#include "kvm/virtio_pci.h"
-
-#include "kvm/disk-image.h"
-#include "kvm/virtio.h"
-#include "kvm/ioport.h"
-#include "kvm/util.h"
-#include "kvm/kvm.h"
-#include "kvm/pci.h"
-
-#include
-#include
-#include
-#include
-
-#define VIRTIO_BLK_IRQ 14
-
-#define NUM_VIRT_QUEUES1
-
-#define VIRTIO_BLK_QUEUE_SIZE 128
-
-struct blk_device {
- struct virtio_blk_configblk_config;
- uint32_thost_features;
- uint32_tguest_features;
- uint16_tconfig_vector;
- uint8_t status;
-
- /* virtio queue */
- uint16_tqueue_selector;
-
- struct virt_queue virt_queues[NUM_VIRT_QUEUES];
-};
-
-#define DISK_SEG_MAX 126
-
-static struct blk_device blk_device = {
- .blk_config = (struct virtio_blk_config) {
- /* VIRTIO_BLK_F_SEG_MAX */
- .seg_max= DISK_SEG_MAX,
- },
- /*
-* Note we don't set VIRTIO_BLK_F_GEOMETRY here so the
-* node kernel will compute disk geometry by own, the
-* same applies to VIRTIO_BLK_F_BLK_SIZE
-*/
- .host_features = (1UL << VIRTIO_BLK_F_SEG_MAX),
-};
-
-static bool virtio_blk_config_in(void *data, unsigned long offset, int size,
uint32_t count)
-{
- uint8_t *config_space = (uint8_t *) &blk_device.blk_config;
-
- if (size != 1 || count != 1)
- return false;
-
- ioport__write8(data, config_space[offset - VIRTIO_PCI_CONFIG_NOMSI]);
-
- return true;
-}
-
-static bool blk_virtio_in(struct kvm *self, uint16_t port, void *data, int
size, uint32_t count)
-{
- unsigned long offset;
-
- offset = port - IOPORT_VIRTIO_BLK;
-
- switch (offset) {
- case VIRTIO_PCI_HOST_FEATURES:
- ioport__write32(data, blk_device.host_features);
- break;
- case VIRTIO_PCI_GUEST_FEATURES:
- return false;
- case VIRTIO_PCI_QUEUE_PFN:
- ioport__write32(data,
blk_device.virt_queues[blk_device.queue_selector].pfn);
- break;
- case VIRTIO_PCI_QUEUE_NUM:
- ioport__write16(data, VIRTIO_BLK_QUEUE_SIZE);
- break;
- case VIRTIO_PCI_QUEUE_SEL:
- case VIRTIO_PCI_QUEUE_NOTIFY:
- return false;
- case VIRTIO_PCI_STATUS:
- ioport__write8(data, blk_device.status);
- break;
- case VIRTIO_PCI_ISR:
- ioport__write8(data, 0x1);
- kvm__irq_line(self, VIRTIO_BLK_IRQ, 0);
- break;
- case VIRTIO_MSI_CONFIG_VECTOR:
- ioport__write16(data, blk_device.config_vector);
- break;
- default:
- return virtio_blk_config_in(data, offset, size, count);
- };
-
- return true;
-}
-
-static bool blk_virti
[PATCH 1/5] kvm tools: change struct device to struct blk_device for block device
Signed-off-by: Asias He
---
tools/kvm/blk-virtio.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/kvm/blk-virtio.c b/tools/kvm/blk-virtio.c
index 9a723cc..e94d7b3 100644
--- a/tools/kvm/blk-virtio.c
+++ b/tools/kvm/blk-virtio.c
@@ -20,7 +20,7 @@
#define VIRTIO_BLK_QUEUE_SIZE 128
-struct device {
+struct blk_device {
struct virtio_blk_configblk_config;
uint32_thost_features;
uint32_tguest_features;
@@ -35,7 +35,7 @@ struct device {
#define DISK_SEG_MAX 126
-static struct device device = {
+static struct blk_device blk_device = {
.blk_config = (struct virtio_blk_config) {
/* VIRTIO_BLK_F_SEG_MAX */
.seg_max= DISK_SEG_MAX,
@@ -50,7 +50,7 @@ static struct device device = {
static bool virtio_blk_config_in(void *data, unsigned long offset, int size,
uint32_t count)
{
- uint8_t *config_space = (uint8_t *) &device.blk_config;
+ uint8_t *config_space = (uint8_t *) &blk_device.blk_config;
if (size != 1 || count != 1)
return false;
@@ -68,12 +68,12 @@ static bool blk_virtio_in(struct kvm *self, uint16_t port,
void *data, int size,
switch (offset) {
case VIRTIO_PCI_HOST_FEATURES:
- ioport__write32(data, device.host_features);
+ ioport__write32(data, blk_device.host_features);
break;
case VIRTIO_PCI_GUEST_FEATURES:
return false;
case VIRTIO_PCI_QUEUE_PFN:
- ioport__write32(data,
device.virt_queues[device.queue_selector].pfn);
+ ioport__write32(data,
blk_device.virt_queues[blk_device.queue_selector].pfn);
break;
case VIRTIO_PCI_QUEUE_NUM:
ioport__write16(data, VIRTIO_BLK_QUEUE_SIZE);
@@ -82,14 +82,14 @@ static bool blk_virtio_in(struct kvm *self, uint16_t port,
void *data, int size,
case VIRTIO_PCI_QUEUE_NOTIFY:
return false;
case VIRTIO_PCI_STATUS:
- ioport__write8(data, device.status);
+ ioport__write8(data, blk_device.status);
break;
case VIRTIO_PCI_ISR:
ioport__write8(data, 0x1);
kvm__irq_line(self, VIRTIO_BLK_IRQ, 0);
break;
case VIRTIO_MSI_CONFIG_VECTOR:
- ioport__write16(data, device.config_vector);
+ ioport__write16(data, blk_device.config_vector);
break;
default:
return virtio_blk_config_in(data, offset, size, count);
@@ -205,13 +205,13 @@ static bool blk_virtio_out(struct kvm *self, uint16_t
port, void *data, int size
switch (offset) {
case VIRTIO_PCI_GUEST_FEATURES:
- device.guest_features = ioport__read32(data);
+ blk_device.guest_features = ioport__read32(data);
break;
case VIRTIO_PCI_QUEUE_PFN: {
struct virt_queue *queue;
void *p;
- queue =
&device.virt_queues[device.queue_selector];
+ queue =
&blk_device.virt_queues[blk_device.queue_selector];
queue->pfn = ioport__read32(data);
@@ -222,7 +222,7 @@ static bool blk_virtio_out(struct kvm *self, uint16_t port,
void *data, int size
break;
}
case VIRTIO_PCI_QUEUE_SEL:
- device.queue_selector = ioport__read16(data);
+ blk_device.queue_selector = ioport__read16(data);
break;
case VIRTIO_PCI_QUEUE_NOTIFY: {
struct virt_queue *queue;
@@ -230,7 +230,7 @@ static bool blk_virtio_out(struct kvm *self, uint16_t port,
void *data, int size
queue_index = ioport__read16(data);
- queue = &device.virt_queues[queue_index];
+ queue = &blk_device.virt_queues[queue_index];
while (queue->vring.avail->idx != queue->last_avail_idx) {
if (!blk_virtio_request(self, queue))
@@ -241,10 +241,10 @@ static bool blk_virtio_out(struct kvm *self, uint16_t
port, void *data, int size
break;
}
case VIRTIO_PCI_STATUS:
- device.status = ioport__read8(data);
+ blk_device.status = ioport__read8(data);
break;
case VIRTIO_MSI_CONFIG_VECTOR:
- device.config_vector= VIRTIO_MSI_NO_VECTOR;
+ blk_device.config_vector= VIRTIO_MSI_NO_VECTOR;
break;
case VIRTIO_MSI_QUEUE_VECTOR:
break;
@@ -285,7 +285,7 @@ void blk_virtio__init(struct kvm *self)
if (!self->disk_image)
return;
- device.blk_config.capacity = self->
Re: [PATCH v2 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
On Fri, 2011-04-08 at 17:54 +0200, Jan Kiszka wrote: > > +} > > Did I miss some change in the plan? I thought we were heading for a > generic, reusable driftfix tool box (or periodic timer service)? Or is > this intentionally an intermediate step? Which is a medium to long way in the future. There is benefit of having this early, since it can deliver real functionality - a reliable hpet, and converting to whatever the api may look like in the future. -- 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: [ANNOUNCE] Native Linux KVM tool
On Thu, 7 Apr 2011 21:14:06 -0500 Anthony Liguori wrote: > If someone was going to seriously go about doing something like this, a > better approach would be to start with QEMU and remove anything non-x86 > and all of the UI/command line/management bits and start there. > > There's nothing more I'd like to see than a viable alternative to QEMU > but ignoring any of the architectural mistakes in QEMU and repeating > them in a new project isn't going to get there. Supporting only a single architecture sounds like a significant architectural mistake... only x86 deserves clean code? -Scott -- 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 v2 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
On 2011-04-08 17:20, Ulrich Obergfell wrote:
> Loss of periodic timer interrupts caused by delayed callbacks and by
> interrupt coalescing is compensated by gradually injecting additional
> interrupts during subsequent timer intervals, starting at a rate of
> one additional interrupt per interval. If further interrupts are lost
> while compensation is in progress, the rate is increased. A limit is
> imposed on the rate and on the 'backlog' of lost interrupts that are
> to be injected. If a guest o/s modifies the comparator register value
> while compensation is in progress, the 'backlog' of lost interrupts
> that are to be injected is scaled to the new value.
>
> Injecting additional timer interrupts to compensate lost interrupts
> can alleviate long term time drift. However, on a short time scale,
> this method can have the side effect of making virtual machine time
> intermittently pass faster than real time (depending on the guest's
> time keeping algorithm). Compensation is disabled by default and can
> be enabled for guests where this behaviour is acceptable.
>
> Signed-off-by: Ulrich Obergfell
> ---
> hw/hpet.c | 58 +-
> 1 files changed, 57 insertions(+), 1 deletions(-)
>
> diff --git a/hw/hpet.c b/hw/hpet.c
> index b5625fb..5a25a96 100644
> --- a/hw/hpet.c
> +++ b/hw/hpet.c
> @@ -42,6 +42,9 @@
>
> #define HPET_MSI_SUPPORT0
>
> +#define MAX_IRQS_TO_INJECT (uint32_t)5000
> +#define MAX_IRQ_RATE (uint32_t)10
> +
> struct HPETState;
> typedef struct HPETTimer { /* timers */
> uint8_t tn; /*timer number*/
> @@ -309,8 +312,11 @@ static const VMStateDescription vmstate_hpet = {
> static void hpet_timer(void *opaque)
> {
> HPETTimer *t = opaque;
> +HPETState *s = t->state;
> uint64_t diff;
>
> +int irq_delivered = 0;
> +uint32_t irq_count = 0;
> uint64_t period = t->period;
> uint64_t cur_tick = hpet_get_ticks(t->state);
>
> @@ -318,13 +324,36 @@ static void hpet_timer(void *opaque)
> if (t->config & HPET_TN_32BIT) {
> while (hpet_time_after(cur_tick, t->cmp)) {
> t->cmp = (uint32_t)(t->cmp + t->period);
> +irq_count++;
> }
> } else {
> while (hpet_time_after64(cur_tick, t->cmp)) {
> t->cmp += period;
> +irq_count++;
> }
> }
> diff = hpet_calculate_diff(t, cur_tick);
> +if (s->driftfix) {
> +if (t->saved_period != t->period) {
> +uint64_t tmp = (t->irqs_to_inject * t->saved_period)
> + + t->ticks_not_accounted;
> +t->irqs_to_inject = tmp / t->period;
> +t->ticks_not_accounted = tmp % t->period;
> +t->saved_period = t->period;
> +}
> +t->irqs_to_inject += irq_count;
> +t->irqs_to_inject = MIN(t->irqs_to_inject, MAX_IRQS_TO_INJECT);
> +if (t->irqs_to_inject > 1) {
> +if (irq_count > 1) {
> +t->irq_rate++;
> +t->irq_rate = MIN(t->irq_rate, MAX_IRQ_RATE);
> +}
> +if (irq_count || t->divisor == 0) {
> +t->divisor = t->irq_rate;
> +}
> +diff /= t->divisor--;
> +}
> +}
Did I miss some change in the plan? I thought we were heading for a
generic, reusable driftfix tool box (or periodic timer service)? Or is
this intentionally an intermediate step?
> qemu_mod_timer(t->qemu_timer,
> qemu_get_clock(vm_clock) +
> (int64_t)ticks_to_ns(diff));
> } else if (t->config & HPET_TN_32BIT && !timer_is_periodic(t)) {
> @@ -335,7 +364,22 @@ static void hpet_timer(void *opaque)
> t->wrap_flag = 0;
> }
> }
> -update_irq(t, 1);
> +if (s->driftfix && timer_is_periodic(t) && period != 0) {
> +if (t->irqs_to_inject) {
> +irq_delivered = update_irq(t, 1);
> +if (irq_delivered) {
> +t->irq_rate = MIN(t->irq_rate, t->irqs_to_inject);
> +t->irqs_to_inject--;
> +} else {
> +if (irq_count) {
> +t->irq_rate++;
> +t->irq_rate = MIN(t->irq_rate, MAX_IRQ_RATE);
> +}
> +}
> +}
> +} else {
> +update_irq(t, 1);
> +}
> }
>
> static void hpet_set_timer(HPETTimer *t)
> @@ -674,6 +718,12 @@ static void hpet_reset(DeviceState *d)
> timer->config |= 0x0004ULL << 32;
> timer->period = 0ULL;
> timer->wrap_flag = 0;
> +
> +timer->saved_period = 0;
> +timer->ticks_not_accounted = 0;
> +timer->irqs_to_inject = 0;
> +timer->irq_rate = 1;
> +timer->divisor = 1;
> }
>
> s->hpet_counter = 0ULL;
> @@
Re: [PATCH v2 1/5] hpet 'driftfix': add hooks required to detect coalesced interrupts (x86 apic only)
On 2011-04-08 17:20, Ulrich Obergfell wrote: > 'target_get_irq_delivered' and 'target_reset_irq_delivered' contain > entry addresses of functions that are utilized by update_irq() to > detect coalesced interrupts. apic code loads these pointers during > initialization. This interface is intended as a temporary helper to allow establishing the driftfix infrastructure, right? Then please leave proper comments behind that it will die once we have a real feedback path for IRQ delivery (that also takes routing into account). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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: [Qemu-devel] [PATCH v2 3/5] hpet 'driftfix': add fields to HPETTimer and VMStateDescription
On 04/08/2011 10:20 AM, Ulrich Obergfell wrote:
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 45847ed..c150da5 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -55,6 +55,11 @@ typedef struct HPETTimer { /* timers */
uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot
32-bit
* mode. Next pop will be actual timer expiration.
*/
+uint64_t saved_period;
+uint64_t ticks_not_accounted;
+uint32_t irqs_to_inject;
+uint32_t irq_rate;
+uint32_t divisor;
} HPETTimer;
typedef struct HPETState {
@@ -248,7 +253,7 @@ static int hpet_post_load(void *opaque, int version_id)
static const VMStateDescription vmstate_hpet_timer = {
.name = "hpet_timer",
-.version_id = 1,
+.version_id = 3,
Why jump from 1 to 3?
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField []) {
@@ -258,6 +263,11 @@ static const VMStateDescription vmstate_hpet_timer = {
VMSTATE_UINT64(fsb, HPETTimer),
VMSTATE_UINT64(period, HPETTimer),
VMSTATE_UINT8(wrap_flag, HPETTimer),
+VMSTATE_UINT64_V(saved_period, HPETTimer, 3),
+VMSTATE_UINT64_V(ticks_not_accounted, HPETTimer, 3),
+VMSTATE_UINT32_V(irqs_to_inject, HPETTimer, 3),
+VMSTATE_UINT32_V(irq_rate, HPETTimer, 3),
+VMSTATE_UINT32_V(divisor, HPETTimer, 3),
We ought to be able to use a subsection keyed off of whether any ticks
are currently accumulated, no?
Regards,
Anthony Liguori
VMSTATE_TIMER(qemu_timer, HPETTimer),
VMSTATE_END_OF_LIST()
}
@@ -265,7 +275,7 @@ static const VMStateDescription vmstate_hpet_timer = {
static const VMStateDescription vmstate_hpet = {
.name = "hpet",
-.version_id = 2,
+.version_id = 3,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.pre_save = hpet_pre_save,
--
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: [Qemu-devel] [PATCH v2 1/5] hpet 'driftfix': add hooks required to detect coalesced interrupts (x86 apic only)
On 04/08/2011 10:20 AM, Ulrich Obergfell wrote:
'target_get_irq_delivered' and 'target_reset_irq_delivered' contain
entry addresses of functions that are utilized by update_irq() to
detect coalesced interrupts. apic code loads these pointers during
initialization.
Signed-off-by: Ulrich Obergfell
---
hw/apic.c |4
sysemu.h |3 +++
vl.c |3 +++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 00907e0..44d8cb3 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
#include "sysbus.h"
#include "trace.h"
#include "kvm.h"
+#include "sysemu.h"
/* APIC Local Vector Table */
#define APIC_LVT_TIMER 0
@@ -1143,6 +1144,9 @@ static SysBusDeviceInfo apic_info = {
static void apic_register_devices(void)
{
+target_get_irq_delivered = apic_get_irq_delivered;
+target_reset_irq_delivered = apic_reset_irq_delivered;
+
sysbus_register_withprop(&apic_info);
}
diff --git a/sysemu.h b/sysemu.h
index 3f7e17e..b5d4f90 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -96,6 +96,9 @@ int qemu_savevm_state_complete(Monitor *mon, QEMUFile *f);
void qemu_savevm_state_cancel(Monitor *mon, QEMUFile *f);
int qemu_loadvm_state(QEMUFile *f);
+extern int (*target_get_irq_delivered)(void);
+extern void (*target_reset_irq_delivered)(void);
It's a bit nicer to use a registration function instead of setting a
global function pointer directly.
Regards,
Anthony Liguori
+
/* SLIRP */
void do_info_slirp(Monitor *mon);
diff --git a/vl.c b/vl.c
index 8bcf2ae..548912a 100644
--- a/vl.c
+++ b/vl.c
@@ -231,6 +231,9 @@ const char *prom_envs[MAX_PROM_ENVS];
const char *nvram = NULL;
int boot_menu;
+int (*target_get_irq_delivered)(void) = 0;
+void (*target_reset_irq_delivered)(void) = 0;
+
typedef struct FWBootEntry FWBootEntry;
struct FWBootEntry {
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm tools: Indicate the end of a KVM session
On Fri, 8 Apr 2011, Ingo Molnar wrote: Right now when a KVM session ends with an incomplete line printk'd without a newline, kvm exits in an ugly way: Applied, thanks! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm tools: Fix segfault when running 'kvm' without a disk image
On Fri, 8 Apr 2011, Ingo Molnar wrote: When running a simple, diskless 'kvm ./bzImage' KVM session we currently segfault at the end of the session: Good catch! Applied both patches, thanks Ingo! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] hpet 'driftfix': add fields to HPETTimer and VMStateDescription
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 45847ed..c150da5 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -55,6 +55,11 @@ typedef struct HPETTimer { /* timers */
uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot 32-bit
* mode. Next pop will be actual timer expiration.
*/
+uint64_t saved_period;
+uint64_t ticks_not_accounted;
+uint32_t irqs_to_inject;
+uint32_t irq_rate;
+uint32_t divisor;
} HPETTimer;
typedef struct HPETState {
@@ -248,7 +253,7 @@ static int hpet_post_load(void *opaque, int version_id)
static const VMStateDescription vmstate_hpet_timer = {
.name = "hpet_timer",
-.version_id = 1,
+.version_id = 3,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField []) {
@@ -258,6 +263,11 @@ static const VMStateDescription vmstate_hpet_timer = {
VMSTATE_UINT64(fsb, HPETTimer),
VMSTATE_UINT64(period, HPETTimer),
VMSTATE_UINT8(wrap_flag, HPETTimer),
+VMSTATE_UINT64_V(saved_period, HPETTimer, 3),
+VMSTATE_UINT64_V(ticks_not_accounted, HPETTimer, 3),
+VMSTATE_UINT32_V(irqs_to_inject, HPETTimer, 3),
+VMSTATE_UINT32_V(irq_rate, HPETTimer, 3),
+VMSTATE_UINT32_V(divisor, HPETTimer, 3),
VMSTATE_TIMER(qemu_timer, HPETTimer),
VMSTATE_END_OF_LIST()
}
@@ -265,7 +275,7 @@ static const VMStateDescription vmstate_hpet_timer = {
static const VMStateDescription vmstate_hpet = {
.name = "hpet",
-.version_id = 2,
+.version_id = 3,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.pre_save = hpet_pre_save,
--
1.6.2.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] hpet 'driftfix': add code in update_irq() to detect coalesced interrupts (x86 apic only)
update_irq() uses a similar method as in 'rtc_td_hack' to detect
coalesced interrupts. The function entry addresses are retrieved
from 'target_get_irq_delivered' and 'target_reset_irq_delivered'.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index c150da5..b5625fb 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -31,6 +31,7 @@
#include "hpet_emul.h"
#include "sysbus.h"
#include "mc146818rtc.h"
+#include "sysemu.h"
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -176,11 +177,12 @@ static inline uint64_t hpet_calculate_diff(HPETTimer *t,
uint64_t current)
}
}
-static void update_irq(struct HPETTimer *timer, int set)
+static int update_irq(struct HPETTimer *timer, int set)
{
uint64_t mask;
HPETState *s;
int route;
+int irq_delivered = 1;
if (timer->tn <= 1 && hpet_in_legacy_mode(timer->state)) {
/* if LegacyReplacementRoute bit is set, HPET specification requires
@@ -205,8 +207,17 @@ static void update_irq(struct HPETTimer *timer, int set)
qemu_irq_raise(s->irqs[route]);
} else {
s->isr &= ~mask;
-qemu_irq_pulse(s->irqs[route]);
+if (s->driftfix && target_get_irq_delivered
+&& target_reset_irq_delivered) {
+target_reset_irq_delivered();
+qemu_irq_raise(s->irqs[route]);
+irq_delivered = target_get_irq_delivered();
+qemu_irq_lower(s->irqs[route]);
+} else {
+qemu_irq_pulse(s->irqs[route]);
+}
}
+return irq_delivered;
}
static void hpet_pre_save(void *opaque)
--
1.6.2.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] hpet 'driftfix': add driftfix property to HPETState and DeviceInfo
driftfix is a 'bit type' property. Compensation of delayed callbacks
and coalesced interrupts can be enabled with the command line option
-global hpet.driftfix=on
driftfix is 'off' (disabled) by default.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index e92b775..45847ed 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -72,6 +72,8 @@ typedef struct HPETState {
uint64_t isr; /* interrupt status reg */
uint64_t hpet_counter; /* main counter */
uint8_t hpet_id; /* instance id */
+
+uint32_t driftfix;
} HPETState;
static uint32_t hpet_in_legacy_mode(HPETState *s)
@@ -738,6 +740,7 @@ static SysBusDeviceInfo hpet_device_info = {
.qdev.props = (Property[]) {
DEFINE_PROP_UINT8("timers", HPETState, num_timers, HPET_MIN_TIMERS),
DEFINE_PROP_BIT("msi", HPETState, flags, HPET_MSI_SUPPORT, false),
+DEFINE_PROP_BIT("driftfix", HPETState, driftfix, 0, false),
DEFINE_PROP_END_OF_LIST(),
},
};
--
1.6.2.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval. If further interrupts are lost
while compensation is in progress, the rate is increased. A limit is
imposed on the rate and on the 'backlog' of lost interrupts that are
to be injected. If a guest o/s modifies the comparator register value
while compensation is in progress, the 'backlog' of lost interrupts
that are to be injected is scaled to the new value.
Injecting additional timer interrupts to compensate lost interrupts
can alleviate long term time drift. However, on a short time scale,
this method can have the side effect of making virtual machine time
intermittently pass faster than real time (depending on the guest's
time keeping algorithm). Compensation is disabled by default and can
be enabled for guests where this behaviour is acceptable.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 58 +-
1 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index b5625fb..5a25a96 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -42,6 +42,9 @@
#define HPET_MSI_SUPPORT0
+#define MAX_IRQS_TO_INJECT (uint32_t)5000
+#define MAX_IRQ_RATE (uint32_t)10
+
struct HPETState;
typedef struct HPETTimer { /* timers */
uint8_t tn; /*timer number*/
@@ -309,8 +312,11 @@ static const VMStateDescription vmstate_hpet = {
static void hpet_timer(void *opaque)
{
HPETTimer *t = opaque;
+HPETState *s = t->state;
uint64_t diff;
+int irq_delivered = 0;
+uint32_t irq_count = 0;
uint64_t period = t->period;
uint64_t cur_tick = hpet_get_ticks(t->state);
@@ -318,13 +324,36 @@ static void hpet_timer(void *opaque)
if (t->config & HPET_TN_32BIT) {
while (hpet_time_after(cur_tick, t->cmp)) {
t->cmp = (uint32_t)(t->cmp + t->period);
+irq_count++;
}
} else {
while (hpet_time_after64(cur_tick, t->cmp)) {
t->cmp += period;
+irq_count++;
}
}
diff = hpet_calculate_diff(t, cur_tick);
+if (s->driftfix) {
+if (t->saved_period != t->period) {
+uint64_t tmp = (t->irqs_to_inject * t->saved_period)
+ + t->ticks_not_accounted;
+t->irqs_to_inject = tmp / t->period;
+t->ticks_not_accounted = tmp % t->period;
+t->saved_period = t->period;
+}
+t->irqs_to_inject += irq_count;
+t->irqs_to_inject = MIN(t->irqs_to_inject, MAX_IRQS_TO_INJECT);
+if (t->irqs_to_inject > 1) {
+if (irq_count > 1) {
+t->irq_rate++;
+t->irq_rate = MIN(t->irq_rate, MAX_IRQ_RATE);
+}
+if (irq_count || t->divisor == 0) {
+t->divisor = t->irq_rate;
+}
+diff /= t->divisor--;
+}
+}
qemu_mod_timer(t->qemu_timer,
qemu_get_clock(vm_clock) + (int64_t)ticks_to_ns(diff));
} else if (t->config & HPET_TN_32BIT && !timer_is_periodic(t)) {
@@ -335,7 +364,22 @@ static void hpet_timer(void *opaque)
t->wrap_flag = 0;
}
}
-update_irq(t, 1);
+if (s->driftfix && timer_is_periodic(t) && period != 0) {
+if (t->irqs_to_inject) {
+irq_delivered = update_irq(t, 1);
+if (irq_delivered) {
+t->irq_rate = MIN(t->irq_rate, t->irqs_to_inject);
+t->irqs_to_inject--;
+} else {
+if (irq_count) {
+t->irq_rate++;
+t->irq_rate = MIN(t->irq_rate, MAX_IRQ_RATE);
+}
+}
+}
+} else {
+update_irq(t, 1);
+}
}
static void hpet_set_timer(HPETTimer *t)
@@ -674,6 +718,12 @@ static void hpet_reset(DeviceState *d)
timer->config |= 0x0004ULL << 32;
timer->period = 0ULL;
timer->wrap_flag = 0;
+
+timer->saved_period = 0;
+timer->ticks_not_accounted = 0;
+timer->irqs_to_inject = 0;
+timer->irq_rate = 1;
+timer->divisor = 1;
}
s->hpet_counter = 0ULL;
@@ -734,6 +784,12 @@ static int hpet_init(SysBusDevice *dev)
timer->qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
timer->tn = i;
timer->state = s;
+
+timer->saved_period = 0;
+timer->ticks_not_accounted = 0;
+timer->irqs_to_inject = 0;
+timer->irq_rate = 1;
+timer->divisor = 1;
}
/* 64-bit main counter; LegacyReplacementRoute. */
--
1.6.2.5
--
To unsubscribe from this list: send the
[PATCH v2 1/5] hpet 'driftfix': add hooks required to detect coalesced interrupts (x86 apic only)
'target_get_irq_delivered' and 'target_reset_irq_delivered' contain
entry addresses of functions that are utilized by update_irq() to
detect coalesced interrupts. apic code loads these pointers during
initialization.
Signed-off-by: Ulrich Obergfell
---
hw/apic.c |4
sysemu.h |3 +++
vl.c |3 +++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 00907e0..44d8cb3 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
#include "sysbus.h"
#include "trace.h"
#include "kvm.h"
+#include "sysemu.h"
/* APIC Local Vector Table */
#define APIC_LVT_TIMER 0
@@ -1143,6 +1144,9 @@ static SysBusDeviceInfo apic_info = {
static void apic_register_devices(void)
{
+target_get_irq_delivered = apic_get_irq_delivered;
+target_reset_irq_delivered = apic_reset_irq_delivered;
+
sysbus_register_withprop(&apic_info);
}
diff --git a/sysemu.h b/sysemu.h
index 3f7e17e..b5d4f90 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -96,6 +96,9 @@ int qemu_savevm_state_complete(Monitor *mon, QEMUFile *f);
void qemu_savevm_state_cancel(Monitor *mon, QEMUFile *f);
int qemu_loadvm_state(QEMUFile *f);
+extern int (*target_get_irq_delivered)(void);
+extern void (*target_reset_irq_delivered)(void);
+
/* SLIRP */
void do_info_slirp(Monitor *mon);
diff --git a/vl.c b/vl.c
index 8bcf2ae..548912a 100644
--- a/vl.c
+++ b/vl.c
@@ -231,6 +231,9 @@ const char *prom_envs[MAX_PROM_ENVS];
const char *nvram = NULL;
int boot_menu;
+int (*target_get_irq_delivered)(void) = 0;
+void (*target_reset_irq_delivered)(void) = 0;
+
typedef struct FWBootEntry FWBootEntry;
struct FWBootEntry {
--
1.6.2.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] hpet 'driftfix': alleviate time drift with HPET periodic timers
Hi, This is version 2 of a series of patches that I originally posted in: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01989.html http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01992.html http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01991.html http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01990.html http://article.gmane.org/gmane.comp.emulators.kvm.devel/69325 http://article.gmane.org/gmane.comp.emulators.kvm.devel/69326 http://article.gmane.org/gmane.comp.emulators.kvm.devel/69327 http://article.gmane.org/gmane.comp.emulators.kvm.devel/69328 I implemented the proposed changes (remove configurability and ifdefs, define 'driftfix' as a property of the HPET device) and I've split the patch into smaller parts (originally 3, now 5). I also included a fix related to scaling 't->irqs_to_inject' when the guest o/s modifies the comparator register value. Please review and please comment. Regards, Uli Ulrich Obergfell (5): hpet 'driftfix': add hooks required to detect coalesced interrupts (x86 apic only) hpet 'driftfix': add driftfix property to HPETState and DeviceInfo hpet 'driftfix': add fields to HPETTimer and VMStateDescription hpet 'driftfix': add code in update_irq() to detect coalesced interrupts (x86 apic only) hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts hw/apic.c |4 +++ hw/hpet.c | 90 +--- sysemu.h |3 ++ vl.c |3 ++ 4 files changed, 95 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm tools: Indicate the end of a KVM session
Right now when a KVM session ends with an incomplete line printk'd
without a newline, kvm exits in an ugly way:
[4.638016] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[4.641668] Rebooting in 1 seconds..spirit:~/tip/tools/kvm>
spirit:~/tip/tools/kvm>
See the shell prompt intermixed with the last line of kernel output.
There's also no indication to the user that everything is fine on the
kvm tool side.
This is somewhat of a beauty wart and also a bit confusing to users.
To clarify and clean up things, add a final printout on normal exits:
[4.654814] Please append a correct "root=" boot option; here are the
available partitions:
[4.584390] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[4.662243] Rebooting in 1 seconds..
# KVM session ended normally.
spirit:~/tip/tools/kvm>
This delimits the kernel output properly and gives feedback to the user
that (despite the scary kernel messages) all fine from the KVM POV.
Signed-off-by: Ingo Molnar
---
tools/kvm/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/main.c b/tools/kvm/main.c
index d8f0c09..bc16502 100644
--- a/tools/kvm/main.c
+++ b/tools/kvm/main.c
@@ -201,6 +201,8 @@ exit_kvm:
disk_image__close(kvm->disk_image);
kvm__delete(kvm);
+ printf("\n # KVM session ended normally.\n");
+
return 0;
panic_kvm:
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm tools: Fix segfault when running 'kvm' without a disk image
When running a simple, diskless 'kvm ./bzImage' KVM session we currently
segfault at the end of the session:
[4.895488] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[4.899371] Rebooting in 1 seconds..
Program received signal SIGSEGV, Segmentation fault.
disk_image__close (self=0x0) at disk-image.c:93
93if (self->ops->close)
(gdb)
Because disk_image__close() assumes that 'self' is never NULL.
Add a NULL check to allow a clean exit.
Signed-off-by: Ingo Molnar
---
tools/kvm/disk-image.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/disk-image.c b/tools/kvm/disk-image.c
index 80999c1..4099720 100644
--- a/tools/kvm/disk-image.c
+++ b/tools/kvm/disk-image.c
@@ -90,6 +90,10 @@ struct disk_image *disk_image__open(const char *filename)
void disk_image__close(struct disk_image *self)
{
+ /* If there was no disk image then there's nothing to do: */
+ if (!self)
+ return;
+
if (self->ops->close)
self->ops->close(self);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] kvm tool: Using the Gitish freamwork to run the virtual machine
- kvm-run.[ch] Adds a new kvm command called 'run'. The most of the code is
copied from main.c.
- main.c is modified to use the functionality provided by framework.
The old code from main.c is moved to kvm-run.c.
Signed-off-by: Prasad Joshi
---
tools/kvm/Makefile | 21 -
tools/kvm/include/kvm/kvm-run.h |6 +
tools/kvm/kvm-run.c | 224 +++
tools/kvm/main.c| 223 ++
4 files changed, 261 insertions(+), 213 deletions(-)
create mode 100644 tools/kvm/include/kvm/kvm-run.h
create mode 100644 tools/kvm/kvm-run.c
diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 55f342d..37e6ae5 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -26,6 +26,11 @@ OBJS += mmio.o
OBJS += pci.o
OBJS += util.o
OBJS += term.o
+OBJS+= util/parse-options.o
+OBJS+= util/strbuf.o
+OBJS+= kvm-help.o
+OBJS+= kvm-cmd.o
+OBJS+= kvm-run.o
DEPS := $(patsubst %.o,%.d,$(OBJS))
@@ -55,7 +60,8 @@ endif
DEFINES+= -D_FILE_OFFSET_BITS=64
DEFINES+= -D_GNU_SOURCE
-CFLAGS += $(CPPFLAGS) $(DEFINES) -Iinclude -I../../include
-I../../arch/$(ARCH)/include/ -Os -g
+KVM_INCLUDE := include
+CFLAGS += $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I../../include
-I../../arch/$(ARCH)/include/ -Os -g
WARNINGS += -Werror
WARNINGS += -Wall
@@ -87,12 +93,22 @@ $(DEPS):
%.d: %.c
$(Q) $(CC) -M -MT $(patsubst %.d,%.o,$@) $(CFLAGS) $< -o $@
+# The header file common-cmds.h is needed for compilation of kvm-help.c.
+kvm-help.d: $(KVM_INCLUDE)/common-cmds.h
+
$(OBJS):
%.o: %.c
$(E) " CC " $@
$(Q) $(CC) -c $(CFLAGS) $< -o $@
+
+$(KVM_INCLUDE)/common-cmds.h: util/generate-cmdlist.sh command-list.txt
+
+$(KVM_INCLUDE)/common-cmds.h: $(wildcard Documentation/kvm-*.txt)
+ $(E) " GEN " $@
+ $(Q) util/generate-cmdlist.sh > $@+ && mv $@+ $@
+
#
# BIOS assembly weirdness
#
@@ -118,7 +134,7 @@ bios/bios-rom.bin: bios/bios-rom.S bios/e820.c
check: $(PROGRAM)
$(MAKE) -C tests
- ./$(PROGRAM) tests/pit/tick.bin
+ ./$(PROGRAM) run --kernel=tests/pit/tick.bin
.PHONY: check
clean:
@@ -129,6 +145,7 @@ clean:
$(Q) rm -f bios/bios-rom.h
$(Q) rm -f $(DEPS) $(OBJS) $(PROGRAM)
$(Q) rm -f cscope.*
+ $(Q) rm -f $(KVM_INCLUDE)/common-cmds.h
.PHONY: clean
KVM_DEV?= /dev/kvm
diff --git a/tools/kvm/include/kvm/kvm-run.h b/tools/kvm/include/kvm/kvm-run.h
new file mode 100644
index 000..13104e2
--- /dev/null
+++ b/tools/kvm/include/kvm/kvm-run.h
@@ -0,0 +1,6 @@
+#ifndef __KVM_RUN_H__
+#define __KVM_RUN_H__
+
+int kvm_cmd_run(int argc, const char **argv, const char *prefix);
+
+#endif
diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
new file mode 100644
index 000..f797a4e
--- /dev/null
+++ b/tools/kvm/kvm-run.c
@@ -0,0 +1,224 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* user defined header files */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* header files for gitish interface */
+#include
+#include
+
+#define DEFAULT_KVM_DEV"/dev/kvm"
+
+#define MB_SHIFT (20)
+#define MIN_RAM_SIZE_MB(64UL)
+#define MIN_RAM_SIZE_BYTE (MIN_RAM_SIZE_MB << MB_SHIFT)
+
+static struct kvm *kvm;
+
+static void handle_sigint(int sig)
+{
+ exit(1);
+}
+
+static void handle_sigquit(int sig)
+{
+ kvm__show_registers(kvm);
+ kvm__show_code(kvm);
+ kvm__show_page_tables(kvm);
+
+ kvm__delete(kvm);
+
+ exit(1);
+}
+
+static u64 ram_size;
+static const char *kernel_cmdline;
+static const char *kernel_filename;
+static const char *initrd_filename;
+static const char *image_filename;
+static const char *kvm_dev;
+static bool single_step = false;
+static bool virtio_console = false;
+extern bool ioport_debug;
+extern int active_console;
+
+static const char * const run_usage[] = {
+ "kvm run []",
+ NULL
+};
+
+static const struct option options[] = {
+ OPT_U64('m', "mem", &ram_size, "Virtual machine memory size in MiB."),
+ OPT_STRING('p', "params", &kernel_cmdline, "params",
+ "Kernel command line arguments"),
+ OPT_STRING('r', "initrd", &initrd_filename, "initrd",
+ "Initial RAM disk image"),
+ OPT_STRING('k', "kernel", &kernel_filename, "kernel",
+ "Kernel to boot in virtual machine"),
+ OPT_STRING('i', "image", &image_filename, "image", "Disk image"),
+ OPT_STRING('d', "kvm-dev", &kvm_dev, "kvm-dev", "KVM device file"),
+ OPT_BOOLEAN('s', "single-step", &single_step,
+ "Enable single stepping"),
+ OPT_BOOLEAN('g', "ioport-debug", &ioport_debug,
+ "Enable ioport debugging"),
+ OPT_BOOLEAN('c', "enable-virtio-console", &vir
[PATCH v3 2/4] kvm tool: Mostly the copied code from perf for argument processing
- parse-options.[ch] has argument processing code.
- types.h: Additional types for argument processing.
- strbuf.[ch]: Added a function prefixcmp to compare string prefix
Signed-off-by: Prasad Joshi
---
tools/kvm/include/kvm/parse-options.h | 161 +
tools/kvm/include/kvm/strbuf.h|6 +
tools/kvm/include/kvm/util.h |8 +
tools/kvm/include/linux/types.h | 12 +
tools/kvm/util/parse-options.c| 570 +
tools/kvm/util/strbuf.c | 13 +
6 files changed, 770 insertions(+), 0 deletions(-)
create mode 100644 tools/kvm/include/kvm/parse-options.h
create mode 100644 tools/kvm/include/kvm/strbuf.h
create mode 100644 tools/kvm/util/parse-options.c
create mode 100644 tools/kvm/util/strbuf.c
diff --git a/tools/kvm/include/kvm/parse-options.h
b/tools/kvm/include/kvm/parse-options.h
new file mode 100644
index 000..b59220d
--- /dev/null
+++ b/tools/kvm/include/kvm/parse-options.h
@@ -0,0 +1,161 @@
+#ifndef __PARSE_OPTIONS_H__
+#define __PARSE_OPTIONS_H__
+
+enum parse_opt_type {
+ /* special types */
+ OPTION_END,
+ OPTION_ARGUMENT,
+ OPTION_GROUP,
+ /* options with no arguments */
+ OPTION_BIT,
+ OPTION_BOOLEAN,
+ OPTION_INCR,
+ OPTION_SET_UINT,
+ OPTION_SET_PTR,
+ /* options with arguments (usually) */
+ OPTION_STRING,
+ OPTION_INTEGER,
+ OPTION_LONG,
+ OPTION_CALLBACK,
+ OPTION_U64,
+ OPTION_UINTEGER,
+};
+
+enum parse_opt_flags {
+ PARSE_OPT_KEEP_DASHDASH = 1,
+ PARSE_OPT_STOP_AT_NON_OPTION = 2,
+ PARSE_OPT_KEEP_ARGV0 = 4,
+ PARSE_OPT_KEEP_UNKNOWN = 8,
+ PARSE_OPT_NO_INTERNAL_HELP = 16,
+};
+
+enum parse_opt_option_flags {
+ PARSE_OPT_OPTARG = 1,
+ PARSE_OPT_NOARG = 2,
+ PARSE_OPT_NONEG = 4,
+ PARSE_OPT_HIDDEN = 8,
+ PARSE_OPT_LASTARG_DEFAULT = 16,
+};
+
+struct option;
+typedef int parse_opt_cb(const struct option *, const char *arg, int unset);
+/*
+ * `type`::
+ * holds the type of the option, you must have an OPTION_END last in your
+ * array.
+ *
+ * `short_name`::
+ * the character to use as a short option name, '\0' if none.
+ *
+ * `long_name`::
+ * the long option name, without the leading dashes, NULL if none.
+ *
+ * `value`::
+ * stores pointers to the values to be filled.
+ *
+ * `argh`::
+ * token to explain the kind of argument this option wants. Keep it
+ * homogenous across the repository.
+ *
+ * `help`::
+ * the short help associated to what the option does.
+ * Must never be NULL (except for OPTION_END).
+ * OPTION_GROUP uses this pointer to store the group header.
+ *
+ * `flags`::
+ * mask of parse_opt_option_flags.
+ * PARSE_OPT_OPTARG: says that the argument is optionnal (not for BOOLEANs)
+ * PARSE_OPT_NOARG: says that this option takes no argument, for CALLBACKs
+ * PARSE_OPT_NONEG: says that this option cannot be negated
+ * PARSE_OPT_HIDDEN this option is skipped in the default usage, showed in
+ *the long one.
+ *
+ * `callback`::
+ * pointer to the callback to use for OPTION_CALLBACK.
+ *
+ * `defval`::
+ * default value to fill (*->value) with for PARSE_OPT_OPTARG.
+ * OPTION_{BIT,SET_UINT,SET_PTR} store the {mask,integer,pointer} to put in
+ * the value when met.
+ * CALLBACKS can use it like they want.
+ */
+struct option {
+enum parse_opt_type type;
+int short_name;
+const char *long_name;
+void *value;
+const char *argh;
+const char *help;
+
+int flags;
+parse_opt_cb *callback;
+intptr_t defval;
+};
+
+#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
+#define check_vtype(v, type) \
+ (BUILD_BUG_ON_ZERO(!__builtin_types_compatible_p(typeof(v), type)) + v)
+
+#define OPT_INTEGER(s, l, v, h) \
+{ \
+ .type = OPTION_INTEGER, \
+ .short_name = (s), \
+ .long_name = (l), \
+ .value = check_vtype(v, int *), \
+ .help = (h) \
+}
+
+#define OPT_U64(s, l, v, h) \
+{ \
+ .type = OPTION_U64, \
+ .short_name = (s), \
+ .long_name = (l), \
+ .value = check_vtype(v, u64 *), \
+ .help = (h) \
+}
+
+#define OPT_STRING(s, l, v, a, h) \
+{ \
+ .type = OPTION_STRING, \
+ .short_name = (s), \
+ .long_name = (l), \
+ .value = check_vtype(v, const char **), (a), \
+ .help = (h) \
+}
+
+#define OPT_BOOLEAN(s, l, v, h) \
+{ \
+ .type = OPTION_BOOLEAN, \
+ .short_name = (s), \
+ .long_name
[PATCH v3 1/4] kvm tool: Generating list of common kvm tool commands
- The Documentation/ directory will have a text file for each commmand. The
text file should contain the information about the command in manpage format.
- command-list.txt: is a list of common commands used with the kvm tool.
- util/generate-cmdlist.sh: is a shell script that uses command-list.txt and
text files in Documentation/ directory to generate the common-cmds.h file in
the include directory. The header file is furthur used to display a usage
messgae. Almost the entire script is copied from the tools/perf.
Signed-off-by: Prasad Joshi
---
tools/kvm/Documentation/kvm-run.txt | 53 +++
tools/kvm/command-list.txt |5 +++
tools/kvm/util/generate-cmdlist.sh | 24
3 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 tools/kvm/Documentation/kvm-run.txt
create mode 100644 tools/kvm/command-list.txt
create mode 100755 tools/kvm/util/generate-cmdlist.sh
diff --git a/tools/kvm/Documentation/kvm-run.txt
b/tools/kvm/Documentation/kvm-run.txt
new file mode 100644
index 000..c56434f
--- /dev/null
+++ b/tools/kvm/Documentation/kvm-run.txt
@@ -0,0 +1,53 @@
+kvm-run(1)
+
+
+NAME
+
+kvm-run - Start the virtual machine
+
+SYNOPSIS
+
+[verse]
+'kvm run' [-k | --kernel ]
+
+DESCRIPTION
+---
+The command starts a virtual machine.
+
+OPTIONS
+---
+-m::
+--mem=::
+ Virtual machine memory size in MiB.
+
+-p::
+--params::
+ Additional kernel command line arguments.
+
+-r::
+--initrd=::
+ Initial RAM disk image.
+
+-k::
+--kernel=::
+The virtual machine kernel.
+-d
+--kvm-dev=::
+ KVM device file
+
+-i::
+--image=::
+ A disk image file.
+
+-s::
+--single-step:: Enable single stepping.
+
+-g::
+--ioport-debug:: Enable ioport debugging.
+
+-c::
+--enable-virtio-console:: Enable the virtual IO console
+
+SEE ALSO
+
+linkkvm:
diff --git a/tools/kvm/command-list.txt b/tools/kvm/command-list.txt
new file mode 100644
index 000..4eaf399
--- /dev/null
+++ b/tools/kvm/command-list.txt
@@ -0,0 +1,5 @@
+#
+# List of known perf commands.
+# command name category [deprecated] [common]
+#
+kvm-runmainporcelain common
diff --git a/tools/kvm/util/generate-cmdlist.sh
b/tools/kvm/util/generate-cmdlist.sh
new file mode 100755
index 000..c3fd172
--- /dev/null
+++ b/tools/kvm/util/generate-cmdlist.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+echo "/* Automatically generated by $0 */
+struct cmdname_help
+{
+char name[16];
+char help[80];
+};
+
+static struct cmdname_help common_cmds[] = {"
+
+sed -n 's/^kvm-\([^ \t]*\).*common/\1/p' command-list.txt |
+sort |
+while read cmd
+do
+# TODO following sed command should be fixed
+ sed -n '/^NAME/,/^kvm-'"$cmd"'/ {
+/NAME/d
+/--/d
+s/.*kvm-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
+p
+}' "Documentation/kvm-$cmd.txt"
+done
+echo "};"
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] kvm tool: Provides the basic Gitish framework
- kvm-cmd.h: Adds a new structure cmd_struct to create a table of commands
and callback function. The structure was copied from tools/perf
- kvm-cmd.c: implements two main functions for command processing.
kvm_get_command(): searches table for specific command.
handle_command(): invokes the callback function for a given command.
- kvm-help.[ch] Implements the kvm help command. The function
list_common_cmds_help() is a copy of similar function in tools/perf.
Signed-off-by: Prasad Joshi
---
tools/kvm/include/kvm/kvm-cmd.h | 12
tools/kvm/include/kvm/kvm-help.h |6
tools/kvm/kvm-cmd.c | 55 ++
tools/kvm/kvm-help.c | 43 +
4 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 tools/kvm/include/kvm/kvm-cmd.h
create mode 100644 tools/kvm/include/kvm/kvm-help.h
create mode 100644 tools/kvm/kvm-cmd.c
create mode 100644 tools/kvm/kvm-help.c
diff --git a/tools/kvm/include/kvm/kvm-cmd.h b/tools/kvm/include/kvm/kvm-cmd.h
new file mode 100644
index 000..8d5fca5
--- /dev/null
+++ b/tools/kvm/include/kvm/kvm-cmd.h
@@ -0,0 +1,12 @@
+#ifndef __KVM_CMD_H__
+#define __KVM_CMD_H__
+
+struct cmd_struct {
+ const char *cmd;
+ int (*fn)(int, const char **, const char *);
+ int option;
+};
+
+int handle_command(struct cmd_struct *command, int argc, const char **argv);
+
+#endif
diff --git a/tools/kvm/include/kvm/kvm-help.h b/tools/kvm/include/kvm/kvm-help.h
new file mode 100644
index 000..2946743
--- /dev/null
+++ b/tools/kvm/include/kvm/kvm-help.h
@@ -0,0 +1,6 @@
+#ifndef __KVM_HELP_H__
+#define __KVM_HELP_H__
+
+int kvm_cmd_help(int argc, const char **argv, const char *prefix);
+
+#endif
diff --git a/tools/kvm/kvm-cmd.c b/tools/kvm/kvm-cmd.c
new file mode 100644
index 000..3c15006
--- /dev/null
+++ b/tools/kvm/kvm-cmd.c
@@ -0,0 +1,55 @@
+#include
+#include
+#include
+
+#include
+
+/* user defined header files */
+#include
+
+/* kvm_get_command: Searches the command in an array of the commands and
+ returns a pointer to cmd_struct if a match is found.
+
+ Input parameters:
+ command: Array of possible commands. The last entry in the array must be
+NULL.
+ cmd: A string command to search in the array
+
+ Return Value:
+ NULL: If the cmd is not matched with any of the command in the command array
+ p: Pointer to cmd_struct of the matching command
+ */
+static struct cmd_struct *kvm_get_command(struct cmd_struct *command,
+ const char *cmd)
+{
+ struct cmd_struct *p = command;
+
+ while (p->cmd) {
+ if (!strcmp(p->cmd, cmd))
+ return p;
+ p++;
+ }
+ return NULL;
+}
+
+int handle_command(struct cmd_struct *command, int argc, const char **argv)
+{
+ struct cmd_struct *p;
+ const char *prefix = NULL;
+
+ if (!argv || !*argv) {
+ p = kvm_get_command(command, "help");
+ assert(p);
+ return p->fn(argc, argv, prefix);
+ }
+
+ p = kvm_get_command(command, argv[0]);
+ if (!p) {
+ p = kvm_get_command(command, "help");
+ assert(p);
+ p->fn(0, NULL, prefix);
+ return EINVAL;
+ }
+
+ return p->fn(argc - 1, &argv[1], prefix);
+}
diff --git a/tools/kvm/kvm-help.c b/tools/kvm/kvm-help.c
new file mode 100644
index 000..5506807
--- /dev/null
+++ b/tools/kvm/kvm-help.c
@@ -0,0 +1,43 @@
+#include
+#include
+
+/* user defined headers */
+#include
+
+#include
+#include
+
+
+const char kvm_usage_string[] =
+ "kvm [--version] [--help] COMMAND [ARGS]";
+
+const char kvm_more_info_string[] =
+ "See 'kvm help COMMAND' for more information on a specific command.";
+
+
+static void list_common_cmds_help(void)
+{
+ unsigned int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ if (longest < strlen(common_cmds[i].name))
+ longest = strlen(common_cmds[i].name);
+ }
+
+ puts(" The most commonly used kvm commands are:");
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ printf(" %-*s ", longest, common_cmds[i].name);
+ puts(common_cmds[i].help);
+ }
+}
+
+int kvm_cmd_help(int argc, const char **argv, const char *prefix)
+{
+ if (!argv || !*argv) {
+ printf("\n usage: %s\n\n", kvm_usage_string);
+ list_common_cmds_help();
+ printf("\n %s\n\n", kvm_more_info_string);
+ return 0;
+ }
+ return 0;
+}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] KVM test: Modify kvm_utils.run_tests to include non fatal failures
So now if a error.TestWarn is thrown, dependent tests can run
just fine.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/kvm_utils.py | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index ff9ee17..8b908ff 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -1150,7 +1150,10 @@ def run_tests(parser, job):
for test_name in status_dict.keys():
if not dep in test_name:
continue
-if not status_dict[test_name]:
+# So the only really non-fatal state is WARN,
+# All the others make it not safe to proceed with dependency
+# execution
+if status_dict[test_name] not in ['GOOD', 'WARN']:
dependencies_satisfied = False
break
if dependencies_satisfied:
@@ -1163,8 +1166,9 @@ def run_tests(parser, job):
# We need only one execution, profiled, hence we're passing
# the profile_only parameter to job.run_test().
-current_status = job.run_test("kvm", params=dict, tag=test_tag,
- iterations=test_iterations,
+current_status = job.run_test_detail("kvm", params=dict,
+ tag=test_tag,
+ iterations=test_iterations,
profile_only= bool(profilers) or
None)
for profiler in profilers:
@@ -1175,8 +1179,9 @@ def run_tests(parser, job):
else:
# We will force the test to fail as TestNA during preprocessing
dict['dependency_failed'] = 'yes'
-current_status = job.run_test("kvm", params=dict, tag=test_tag,
- iterations=test_iterations,
+current_status = job.run_test_detail("kvm", params=dict,
+ tag=test_tag,
+ iterations=test_iterations,
profile_only= bool(profilers) or
None)
status_dict[dict.get("name")] = current_status
--
1.7.4.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] KVM test: Refine image_check function
With the accumulated experience running the KVM test to
perform quality control on our KVM branches, we noticed
that qemu-img check might return exit code != 0, but
not all failures mean some data integrity problem happend.
After checking qemu-img check code, we found out that:
Exit code 1: Check error. Problem on the check itself,
most of the time harmless, however there is some risk
of data corruption.
Exit code 2: Data corruption error. This means for sure
that disk corruption happened. Bad, bad.
Exit code 3: Leaked clusters error. This means some
leaked clusters were found on the image, which is not
a data corruption condition, it only means that some
space is going to be lost on that image.
So, refine the logic of the image_check function, executing
qemu-img check and verifying its exit code
Exit code 1: Raise error.TestWarn
Exit code 2: Raise VMImageError
Exit code 3: Raise error.TestWarn
This change, together with the new logic of the KVM
run_tests() utility function, will make it possible
to still fail tests in cases 1) and 3), but letting
the dependencies to be executed.
Changes from v1:
* Print stdout and stderr of the checking program in cases 1) and
2), to help debug eventual problems.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/kvm_vm.py | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index 8114670..f004f4f 100755
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -294,10 +294,31 @@ def check_image(params, root_dir):
except error.CmdError:
logging.error("Error getting info from image %s",
image_filename)
-try:
-utils.system("%s check %s" % (qemu_img_cmd, image_filename))
-except error.CmdError:
+
+cmd_result = utils.run("%s check %s" %
+ (qemu_img_cmd, image_filename),
+ ignore_status=True)
+# Error check, large chances of a non-fatal problem.
+# There are chances that bad data was skipped though
+if cmd_result.exit_status == 1:
+for e_line in cmd_result.stdout.splitlines():
+logging.error("[stdout] %s", e_line)
+for e_line in cmd_result.stderr.splitlines():
+logging.error("[stderr] %s", e_line)
+raise error.TestWarn("qemu-img check error. Some bad data in "
+ "the image may have gone unnoticed")
+# Exit status 2 is data corruption for sure, so fail the test
+elif cmd_result.exit_status == 2:
+for e_line in cmd_result.stdout.splitlines():
+logging.error("[stdout] %s", e_line)
+for e_line in cmd_result.stderr.splitlines():
+logging.error("[stderr] %s", e_line)
raise VMImageCheckError(image_filename)
+# Leaked clusters, they are known to be harmless to data integrity
+elif cmd_result.exit_status == 3:
+raise error.TestWarn("Leaked clusters were noticed during "
+ "image check. No data integrity problem "
+ "was found though.")
else:
if not os.path.exists(image_filename):
--
1.7.4.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] KVM test: Fail a test right away if 'dependency_fail = yes' is on params
When the KVM config file parser generates the list of tests,
it will generate a full list of dicts, each dict maps to a
test to be executed. However, due to the design of our
dependency system, we skip running tests that had a dependency
failure.
While fair, this also masks the fact that the tests that were
not executed are indeed failures (test couldn't run because a
dependency failed). So test jobs that had very serious problem
(say, kvm build failed so every other test failed in sequence),
will yield fairly reasonable PASS rates, that can fool developers.
So, here's what we are going to do to solve this:
* When a dependency fails, when it comes to execute a dependency
test, don't just skip it. Execute it in a way that it will always
throw a TestNA exception.
In order to do that:
* Introduce an extra parameter 'dependency_fail = yes' on the
dependent test 'params' dict.
* Make test load code to fail the test right away with
TestNA whenever params[dependency_fail] is 'yes'.
Changes from v2:
* Move failing test code from kvm_preprocessing to kvm.py. Conceptually
that logic belongs to the high level kvm test load code.
* Fix typo on the TestNAError class name.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/kvm.py |5 +
client/tests/kvm/kvm_preprocessing.py |1 -
client/tests/kvm/kvm_utils.py |6 +-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py
index b88fd51..c22293a 100644
--- a/client/tests/kvm/kvm.py
+++ b/client/tests/kvm/kvm.py
@@ -27,6 +27,11 @@ class kvm(test.test):
# Convert params to a Params object
params = kvm_utils.Params(params)
+# If a dependency test prior to this test has failed, let's fail
+# it right away as TestNA.
+if params("dependency_failed") == 'yes':
+raise error.TestNAError("Test dependency failed")
+
# Report the parameters we've received and write them as keyvals
logging.debug("Test parameters:")
keys = params.keys()
diff --git a/client/tests/kvm/kvm_preprocessing.py
b/client/tests/kvm/kvm_preprocessing.py
index 515e3a5..dbe5d19 100644
--- a/client/tests/kvm/kvm_preprocessing.py
+++ b/client/tests/kvm/kvm_preprocessing.py
@@ -194,7 +194,6 @@ def preprocess(test, params, env):
@param env: The environment (a dict-like object).
"""
error.context("preprocessing")
-
# Start tcpdump if it isn't already running
if "address_cache" not in env:
env["address_cache"] = {}
diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index 5ecbd4a..ff9ee17 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -1173,7 +1173,11 @@ def run_tests(parser, job):
if not current_status:
failed = True
else:
-current_status = False
+# We will force the test to fail as TestNA during preprocessing
+dict['dependency_failed'] = 'yes'
+current_status = job.run_test("kvm", params=dict, tag=test_tag,
+ iterations=test_iterations,
+ profile_only= bool(profilers) or
None)
status_dict[dict.get("name")] = current_status
return not failed
--
1.7.4.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] client job: Introduce a run_test_detail method
For the KVM test, we have for a long time a system of
'test dependencies': If a dependency test, such as guest
installation has failed, it is not possible to run subsequent
tests for obvious reasons. There are minor failures though,
that don't necessarily block other tests, such as some specific
types of image problems found on a guest after the routine check.
However, job.run_test() returns a boolean, making it not possible
to fail a test, so we are not ignoring problems, and at the same
time, execute dependent tests, because the failure was deemed to
be non-fatal. Therefore, introduce and additional method,
job.run_test_detail(), that returns the test status (see all
possible statuses on client/common_lib/error.py), rather than
a boolean. With this finer grained control, we can implement the
kvm subtest dependency system in a better way.
Strategy: refactor the run_test method into _run_test_base
and creating the 2 implementations, run_test, and
run_test_detail in terms of _run_test_base.
Risk: High (touches a very very visible test writer API)
Tests executed: run_test continues to work, run_test_detail
provides the correct return codes and change does not break
job_unittest.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/bin/job.py | 54 +---
1 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/client/bin/job.py b/client/bin/job.py
index 97412c0..9effcdb 100644
--- a/client/bin/job.py
+++ b/client/bin/job.py
@@ -539,10 +539,9 @@ class base_client_job(base_job.base_job):
raise error.UnhandledTestError(e)
-@_run_test_complete_on_exit
-def run_test(self, url, *args, **dargs):
+def _run_test_base(self, url, *args, **dargs):
"""
-Summon a test object and run it.
+Prepares arguments and run functions to run_test and run_test_detail.
@param url A url that identifies the test to run.
@param tag An optional keyword argument that will be added to the
@@ -550,7 +549,11 @@ class base_client_job(base_job.base_job):
@param subdir_tag An optional keyword argument that will be added
to the subdir name.
-@returns True if the test passes, False otherwise.
+@returns:
+subdir: Test subdirectory
+testname: Test name
+group_func: Actual test run function
+timeout: Test timeout
"""
group, testname = self.pkgmgr.get_package_name(url, 'test')
testname, subdir, tag = self._build_tagged_test_name(testname, dargs)
@@ -573,6 +576,25 @@ class base_client_job(base_job.base_job):
else:
self.record('GOOD', subdir, testname, 'completed successfully')
+return (subdir, testname, group_func, timeout)
+
+
+@_run_test_complete_on_exit
+def run_test(self, url, *args, **dargs):
+"""
+Summon a test object and run it.
+
+@param url A url that identifies the test to run.
+@param tag An optional keyword argument that will be added to the
+test and subdir name.
+@param subdir_tag An optional keyword argument that will be added
+to the subdir name.
+
+@returns True if the test passes, False otherwise.
+"""
+(subdir, testname, group_func, timeout) = self._run_test_base(url,
+ *args,
+ **dargs)
try:
self._rungroup(subdir, testname, group_func, timeout)
return True
@@ -585,6 +607,30 @@ class base_client_job(base_job.base_job):
# UnhandledTestError that is caught above.
+@_run_test_complete_on_exit
+def run_test_detail(self, url, *args, **dargs):
+"""
+Summon a test object and run it, returning test status.
+
+@param url A url that identifies the test to run.
+@param tag An optional keyword argument that will be added to the
+test and subdir name.
+@param subdir_tag An optional keyword argument that will be added
+to the subdir name.
+
+@returns Test status
+@see: client/common_lib/error.py, exit_status
+"""
+(subdir, testname, group_func, timeout) = self._run_test_base(url,
+ *args,
+ **dargs)
+try:
+self._rungroup(subdir, testname, group_func, timeout)
+return 'GOOD'
+except error.TestBaseException, detail:
+return detail.exit_status
+
+
def _rungroup(self, subdir, testname, function, timeout, *args, **dargs):
"""\
subdir:
--
1.7.4.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
M
[PATCH 0/4] Introducing the concept of non fatal failures in KVM autotest v2
In order to fix make it possible to throw test errors in certain special conditions, yet executing dependent tests,introduced a new public job API and modified kvm_utils.run_tests logic. Also modified preprocessing code to provide a feature asked for a long time: make tests with dependencies failed to execute, but to throw a TestNA exception, so our developers are not fooled with a high PASS rate on a job that had a central dependency (such as KVM build) failed. More info on the commit messages. John, I would like you to review only the first patch, as it touches a very visible autotest API, so it is high risk. Lucas Meneghel Rodrigues (4): client job: Introduce a run_test_detail method KVM test: Fail a test right away if 'dependency_fail = yes' is on params KVM test: Refine image_check function KVM test: Modify kvm_utils.run_tests to include non fatal failures client/bin/job.py | 54 ++-- client/tests/kvm/kvm.py |5 +++ client/tests/kvm/kvm_preprocessing.py |1 - client/tests/kvm/kvm_utils.py | 17 -- client/tests/kvm/kvm_vm.py| 27 ++-- 5 files changed, 92 insertions(+), 12 deletions(-) -- 1.7.4.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm tools: Emit a more informative error message when /dev/kvm does not open
When for some reason virtualization is not available on a box, the user
gets this cryptic error message:
open: No such device
The user has no idea what happened - what is being opened and why is
there no such device?
This happens on one of my boxes, where there's VMX support indicated
in the CPU feature flags but where modules do not load because the
BIOS has virtualization disabled. The KVM kernel subsystem emits a
warning into the syslog:
kvm: disabled by bios
But unfortunatey tools cannot really recover that error reason in any sane,
programmatic way when accessing /dev/kvm.
So do the best we can, we suggest to the user to look into the syslog for
the reason of the error:
Fatal: '/dev/kvm' KVM driver not available.
# (If the KVM module is loaded then 'dmesg' may offer further clues about the
failure.)
Also improve the fallback error message from 'open: No such device' to:
Fatal, could not open /dev/kvm: No such device
... should there be any future error returns that are neither -ENOENT,
nor -ENODEV.
Signed-off-by: Ingo Molnar
---
tools/kvm/kvm.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index 93d48b3..188cd98 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -174,8 +174,12 @@ struct kvm *kvm__init(const char *kvm_dev, unsigned long
ram_size)
if (self->sys_fd < 0) {
if (errno == ENOENT)
die("'%s' not found. Please make sure your kernel has
CONFIG_KVM enabled and that the KVM modules are loaded.", kvm_dev);
+ if (errno == ENODEV)
+ die("'%s' KVM driver not available.\n # (If the KVM
module is loaded then 'dmesg' may offer further clues about the failure.)",
kvm_dev);
- die_perror("open");
+ fprintf(stderr, " Fatal, could not open %s: ", kvm_dev);
+ perror(NULL);
+ exit(1);
}
ret = ioctl(self->sys_fd, KVM_GET_API_VERSION, 0);
--
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: [ANNOUNCE] Native Linux KVM tool
On Fri, Apr 08, 2011 at 01:32:24PM +0400, Cyrill Gorcunov wrote: > > It seems there is a misunderstanding. KVM-tool is quite far from been KVM > replacement (if ever). And what we're doing -- extremely tiny/small HV which > would help us to debug/test kernel code. If that's true, then perhaps the command-line invocation shouldn't be named "kvm"? The collision on the name of executable that claims that it will replace the kvm shipped in qemu seems to make the claim quite clearly that it's going to replace qemu's kvm in short order? - Ted -- 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 v2 kvm tool: 4/4] Using the Gitish freamwork to run the virtual machine
On Fri, Apr 8, 2011 at 2:48 PM, Pekka Enberg wrote: > Hi Prasad, > > Please don't put 'kvm tool' inside the brackets in the subject line. All > that gets stripped away. The correct form is: > > [PATCH v2 4/4] kvm tools: Using the Gitish framework to run the VM oh okay! > > On Fri, 8 Apr 2011, Prasad Joshi wrote: >> >> - kvm-run.[ch] Adds a new kvm command called 'run'. The most of the code >> is >> copied from main.c. >> >> - main.c is modified to use the functionality provided by framework. >> The old code from main.c is moved to kvm-run.c. >> >> Signed-off-by: Prasad Joshi > > This needs bit more fine-tuning: > > - The '--mem' command must not be a mandatory option. Use the > current default instead. > > - This form must still work after the patch: > > ./kvm run /boot/vmlinuz-2.6.39-rc2+ > > [ Btw, please fix up 'make check' in this patch as well. ] I will make the changes and resend all of the patches. Thanks a lot for your review comments. Thanks and Regards, Prasad > > Pekka > -- 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: [ANNOUNCE] Native Linux KVM tool
On 04/08/2011 12:14 AM, Pekka Enberg wrote:
Hey, feel free to help out! ;-)
I don't agree that a working 2500 LOC program is 'repeating the same
architectural mistakes' as QEMU. I hope you realize that we've gotten
here with just three part-time hackers working from their proverbial
basements. So what you call mistakes, we call features for the sake of
simplicity.
And by all means, it's a good accomplishment.
But the mistakes I'm referring to aren't missing bits of code. It's
that the current code makes really bad assumptions.
An example is ioport_ops. This maps directly to
ioport_{read,write}_table in QEMU. Then you use ioport__register() to
register entries in this table similar register_ioport_{read,write}() in
QEMU.
The use of a struct is a small improvement but the fundamental design is
flawed because it models a view of hardware where all devices are
directly connected to the CPU. This is not how hardware works at all.
On the PC QEMU tries to emulate, a PIO operation flows from the CPU to
the i440fx. The i440fx will do the first level of decoding treating the
PCI host controller ports specially and then posting any I/Os in the PCI
port range to the PCI bus. If no device selects these ports, or the
ports fall into the non-PCI range, the I/O request is then posted to the
PIIX3.
The PIIX3 will handle a good chunk of the I/O requests (via it's Super
I/O chipset) and the remainder will be posted to the ISA bus. One or
more ISA devices may then react to these posted I/O operation.
Really, having a flat table doesn't make sense. You should just send
everything to an i440fx directly. Then the i440fx should decode what it
can, and send it to the next level, and so forth.
You can get 90% of the way to working device model without modelling
this type of flow, but you hit a wall pretty quickly as it's not unusual
for PCI controllers to manipulate I/O requests in some fashion
(particularly on non-x86 platforms). If you treat everything as
directly attached to the CPU, it's impossible to model this.
Likewise, the same flow is true in the opposite direction. You use
guest_flat_to_host() which assumes a linear mapping of guest memory to
host memory. We used to do that too in QEMU (phys_ram_base + X). It
took a long time to get rid of that assumption in QEMU.
There are multiple problems with this sort of assumption. The first is
that you treat all devices as being directly attached to the memory
controller. As with I/O instruction dispatch, this is not the case, and
there are many PCI controllers that will munge these accesses (think
IOMMU, for instance). The second is you assume that you're not doing
I/O to device memory, but this does happen in practice. The
cpu_physical_memory_rw() API is careful to support cases where you're
writing data to I/O memory.
The other big problem here is that if you have open access to guest
memory like this, you cannot easily track dirty information. Userspace
accesses to guest memory will not result in KVM updating the guest dirty
bitmap. You can add another API to explicitly set dirty bits (and
that's exactly what we did a few years ago) but then you'll get
extremely subtle bugs in migration if you're missing a dirty update
somewhere. This is exactly how our API evolved in QEMU.
As I said earlier, there are very good reasons we do the things we do in
QEMU. We're a large code base and there's far too much of the code base
that noone cares about enough but that users are happy with. It's far
too hard to make broad sweeping changes right now (although that's
something we're trying to improve).
But I'd strongly suggest taking some of the advise being offered here.
Don't ignore the hard problems to start out with because as the code
base grows, it'll become more difficult to fix those. That's not to say
that you need to implement migration tomorrow, but at least keep the
constraints in mind and make sure that you're designing interfaces that
let you do things like keep an updated dirty bitmap when you do memory
accesses in userspace.
I also don't agree with this sentiment that unless we have SMP,
migration, yadda yadda yadda, now, it's impossible to change that in
the future. It ignores the fact that this is exactly how the Linux
kernel evolved
Over the course of 20 years. By my count, we still have another decade
of refactoring before I can get on top of my ivory tower and call every
other project terrible.
and the fact that we're aggressively trying to keep the
code size as small and tidy as possible so that changing things is as
easy as possible.
I've looked at QEMU sources over the years and especially over the
past year and I think you might be way too familiar with its inner
workings to see how complex (even the core code) has become for
someone who isn't familiar with it.
I have no doubts about the complexity of QEMU. But the 'goo' factor is
not due to complexity, it'
Re: [PATCH v2 kvm tool: 4/4] Using the Gitish freamwork to run the virtual machine
Hi Prasad, Please don't put 'kvm tool' inside the brackets in the subject line. All that gets stripped away. The correct form is: [PATCH v2 4/4] kvm tools: Using the Gitish framework to run the VM On Fri, 8 Apr 2011, Prasad Joshi wrote: - kvm-run.[ch] Adds a new kvm command called 'run'. The most of the code is copied from main.c. - main.c is modified to use the functionality provided by framework. The old code from main.c is moved to kvm-run.c. Signed-off-by: Prasad Joshi This needs bit more fine-tuning: - The '--mem' command must not be a mandatory option. Use the current default instead. - This form must still work after the patch: ./kvm run /boot/vmlinuz-2.6.39-rc2+ [ Btw, please fix up 'make check' in this patch as well. ] Pekka -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 kvm tool: 4/4] Using the Gitish freamwork to run the virtual machine
- kvm-run.[ch] Adds a new kvm command called 'run'. The most of the code is
copied from main.c.
- main.c is modified to use the functionality provided by framework.
The old code from main.c is moved to kvm-run.c.
Signed-off-by: Prasad Joshi
---
tools/kvm/Makefile | 19 +++-
tools/kvm/include/kvm/kvm-run.h |6 +
tools/kvm/kvm-run.c | 222 ++
tools/kvm/main.c| 223 ++
4 files changed, 258 insertions(+), 212 deletions(-)
create mode 100644 tools/kvm/include/kvm/kvm-run.h
create mode 100644 tools/kvm/kvm-run.c
diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 55f342d..9a2819d 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -26,6 +26,11 @@ OBJS += mmio.o
OBJS += pci.o
OBJS += util.o
OBJS += term.o
+OBJS+= util/parse-options.o
+OBJS+= util/strbuf.o
+OBJS+= kvm-help.o
+OBJS+= kvm-cmd.o
+OBJS+= kvm-run.o
DEPS := $(patsubst %.o,%.d,$(OBJS))
@@ -55,7 +60,8 @@ endif
DEFINES+= -D_FILE_OFFSET_BITS=64
DEFINES+= -D_GNU_SOURCE
-CFLAGS += $(CPPFLAGS) $(DEFINES) -Iinclude -I../../include
-I../../arch/$(ARCH)/include/ -Os -g
+KVM_INCLUDE := include
+CFLAGS += $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I../../include
-I../../arch/$(ARCH)/include/ -Os -g
WARNINGS += -Werror
WARNINGS += -Wall
@@ -87,12 +93,22 @@ $(DEPS):
%.d: %.c
$(Q) $(CC) -M -MT $(patsubst %.d,%.o,$@) $(CFLAGS) $< -o $@
+# The header file common-cmds.h is needed for compilation of kvm-help.c.
+kvm-help.d: $(KVM_INCLUDE)/common-cmds.h
+
$(OBJS):
%.o: %.c
$(E) " CC " $@
$(Q) $(CC) -c $(CFLAGS) $< -o $@
+
+$(KVM_INCLUDE)/common-cmds.h: util/generate-cmdlist.sh command-list.txt
+
+$(KVM_INCLUDE)/common-cmds.h: $(wildcard Documentation/kvm-*.txt)
+ $(E) " GEN " $@
+ $(Q) util/generate-cmdlist.sh > $@+ && mv $@+ $@
+
#
# BIOS assembly weirdness
#
@@ -129,6 +145,7 @@ clean:
$(Q) rm -f bios/bios-rom.h
$(Q) rm -f $(DEPS) $(OBJS) $(PROGRAM)
$(Q) rm -f cscope.*
+ $(Q) rm -f $(KVM_INCLUDE)/common-cmds.h
.PHONY: clean
KVM_DEV?= /dev/kvm
diff --git a/tools/kvm/include/kvm/kvm-run.h b/tools/kvm/include/kvm/kvm-run.h
new file mode 100644
index 000..13104e2
--- /dev/null
+++ b/tools/kvm/include/kvm/kvm-run.h
@@ -0,0 +1,6 @@
+#ifndef __KVM_RUN_H__
+#define __KVM_RUN_H__
+
+int kvm_cmd_run(int argc, const char **argv, const char *prefix);
+
+#endif
diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
new file mode 100644
index 000..1df0007
--- /dev/null
+++ b/tools/kvm/kvm-run.c
@@ -0,0 +1,222 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* user defined header files */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* header files for gitish interface */
+#include
+#include
+
+#define DEFAULT_KVM_DEV"/dev/kvm"
+
+#define MB_SHIFT (20)
+#define MIN_RAM_SIZE_MB(64UL)
+#define MIN_RAM_SIZE_BYTE (MIN_RAM_SIZE_MB << MB_SHIFT)
+
+static struct kvm *kvm;
+
+static void handle_sigint(int sig)
+{
+ exit(1);
+}
+
+static void handle_sigquit(int sig)
+{
+ kvm__show_registers(kvm);
+ kvm__show_code(kvm);
+ kvm__show_page_tables(kvm);
+
+ kvm__delete(kvm);
+
+ exit(1);
+}
+
+static u64 ram_size;
+static const char *kernel_cmdline;
+static const char *kernel_filename;
+static const char *initrd_filename;
+static const char *image_filename;
+static const char *kvm_dev;
+static bool single_step = false;
+static bool virtio_console = false;
+extern bool ioport_debug;
+extern int active_console;
+
+static const char * const run_usage[] = {
+ "kvm run []",
+ NULL
+};
+
+static const struct option options[] = {
+ OPT_U64('m', "mem", &ram_size, "Virtual machine memory size in MiB."),
+ OPT_STRING('p', "params", &kernel_cmdline, "params",
+ "Kernel command line arguments"),
+ OPT_STRING('i', "initrd", &initrd_filename, "initrd",
+ "Initial RAM disk image"),
+ OPT_STRING('k', "kernel", &kernel_filename, "kernel",
+ "Kernel to boot in virtual machine"),
+ OPT_STRING('d', "image", &image_filename, "image", "Disk image"),
+ OPT_STRING('k', "kvm-dev", &kvm_dev, "kvm-dev", "KVM device file"),
+ OPT_BOOLEAN('s', "single-step", &single_step, "Enable single stepping"),
+ OPT_BOOLEAN('g', "ioport-debug", &ioport_debug,
+ "Enable ioport debugging"),
+ OPT_BOOLEAN('c', "enable-virtio-console", &virtio_console,
+ "Enable the virtual IO console"),
+ OPT_END()
+};
+
+int kvm_cmd_run(int argc, const char **argv, const char *prefix)
+{
+ static char real_cmdline[2048];
+
+ signal(SIGQUIT, handle_sigquit);
+ si
[PATCH v2 kvm tool: 2/4] Mostly the copied code from perf for argument processing
- parse-options.[ch] has argument processing code.
- types.h: Additional types for argument processing.
- strbuf.[ch]: Added a function prefixcmp to compare string prefix
Signed-off-by: Prasad Joshi
---
tools/kvm/include/kvm/parse-options.h | 161 +
tools/kvm/include/kvm/strbuf.h|6 +
tools/kvm/include/kvm/util.h |8 +
tools/kvm/include/linux/types.h | 12 +
tools/kvm/util/parse-options.c| 570 +
tools/kvm/util/strbuf.c | 13 +
6 files changed, 770 insertions(+), 0 deletions(-)
create mode 100644 tools/kvm/include/kvm/parse-options.h
create mode 100644 tools/kvm/include/kvm/strbuf.h
create mode 100644 tools/kvm/util/parse-options.c
create mode 100644 tools/kvm/util/strbuf.c
diff --git a/tools/kvm/include/kvm/parse-options.h
b/tools/kvm/include/kvm/parse-options.h
new file mode 100644
index 000..b59220d
--- /dev/null
+++ b/tools/kvm/include/kvm/parse-options.h
@@ -0,0 +1,161 @@
+#ifndef __PARSE_OPTIONS_H__
+#define __PARSE_OPTIONS_H__
+
+enum parse_opt_type {
+ /* special types */
+ OPTION_END,
+ OPTION_ARGUMENT,
+ OPTION_GROUP,
+ /* options with no arguments */
+ OPTION_BIT,
+ OPTION_BOOLEAN,
+ OPTION_INCR,
+ OPTION_SET_UINT,
+ OPTION_SET_PTR,
+ /* options with arguments (usually) */
+ OPTION_STRING,
+ OPTION_INTEGER,
+ OPTION_LONG,
+ OPTION_CALLBACK,
+ OPTION_U64,
+ OPTION_UINTEGER,
+};
+
+enum parse_opt_flags {
+ PARSE_OPT_KEEP_DASHDASH = 1,
+ PARSE_OPT_STOP_AT_NON_OPTION = 2,
+ PARSE_OPT_KEEP_ARGV0 = 4,
+ PARSE_OPT_KEEP_UNKNOWN = 8,
+ PARSE_OPT_NO_INTERNAL_HELP = 16,
+};
+
+enum parse_opt_option_flags {
+ PARSE_OPT_OPTARG = 1,
+ PARSE_OPT_NOARG = 2,
+ PARSE_OPT_NONEG = 4,
+ PARSE_OPT_HIDDEN = 8,
+ PARSE_OPT_LASTARG_DEFAULT = 16,
+};
+
+struct option;
+typedef int parse_opt_cb(const struct option *, const char *arg, int unset);
+/*
+ * `type`::
+ * holds the type of the option, you must have an OPTION_END last in your
+ * array.
+ *
+ * `short_name`::
+ * the character to use as a short option name, '\0' if none.
+ *
+ * `long_name`::
+ * the long option name, without the leading dashes, NULL if none.
+ *
+ * `value`::
+ * stores pointers to the values to be filled.
+ *
+ * `argh`::
+ * token to explain the kind of argument this option wants. Keep it
+ * homogenous across the repository.
+ *
+ * `help`::
+ * the short help associated to what the option does.
+ * Must never be NULL (except for OPTION_END).
+ * OPTION_GROUP uses this pointer to store the group header.
+ *
+ * `flags`::
+ * mask of parse_opt_option_flags.
+ * PARSE_OPT_OPTARG: says that the argument is optionnal (not for BOOLEANs)
+ * PARSE_OPT_NOARG: says that this option takes no argument, for CALLBACKs
+ * PARSE_OPT_NONEG: says that this option cannot be negated
+ * PARSE_OPT_HIDDEN this option is skipped in the default usage, showed in
+ *the long one.
+ *
+ * `callback`::
+ * pointer to the callback to use for OPTION_CALLBACK.
+ *
+ * `defval`::
+ * default value to fill (*->value) with for PARSE_OPT_OPTARG.
+ * OPTION_{BIT,SET_UINT,SET_PTR} store the {mask,integer,pointer} to put in
+ * the value when met.
+ * CALLBACKS can use it like they want.
+ */
+struct option {
+enum parse_opt_type type;
+int short_name;
+const char *long_name;
+void *value;
+const char *argh;
+const char *help;
+
+int flags;
+parse_opt_cb *callback;
+intptr_t defval;
+};
+
+#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
+#define check_vtype(v, type) \
+ (BUILD_BUG_ON_ZERO(!__builtin_types_compatible_p(typeof(v), type)) + v)
+
+#define OPT_INTEGER(s, l, v, h) \
+{ \
+ .type = OPTION_INTEGER, \
+ .short_name = (s), \
+ .long_name = (l), \
+ .value = check_vtype(v, int *), \
+ .help = (h) \
+}
+
+#define OPT_U64(s, l, v, h) \
+{ \
+ .type = OPTION_U64, \
+ .short_name = (s), \
+ .long_name = (l), \
+ .value = check_vtype(v, u64 *), \
+ .help = (h) \
+}
+
+#define OPT_STRING(s, l, v, a, h) \
+{ \
+ .type = OPTION_STRING, \
+ .short_name = (s), \
+ .long_name = (l), \
+ .value = check_vtype(v, const char **), (a), \
+ .help = (h) \
+}
+
+#define OPT_BOOLEAN(s, l, v, h) \
+{ \
+ .type = OPTION_BOOLEAN, \
+ .short_name = (s), \
+ .long_name
[PATCH v2 kvm tool: 3/4] Provides the basic Gitish framework
- kvm-cmd.h: Adds a new structure cmd_struct to create a table of commands
and callback function. The structure was copied from tools/perf
- kvm-cmd.c: implements two main functions for command processing.
kvm_get_command(): searches table for specific command.
handle_command(): invokes the callback function for a given command.
- kvm-help.[ch] Implements the kvm help command. The function
list_common_cmds_help() is a copy of similar function in tools/perf.
Signed-off-by: Prasad Joshi
---
tools/kvm/include/kvm/kvm-cmd.h | 12
tools/kvm/include/kvm/kvm-help.h |6
tools/kvm/kvm-cmd.c | 55 ++
tools/kvm/kvm-help.c | 43 +
4 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 tools/kvm/include/kvm/kvm-cmd.h
create mode 100644 tools/kvm/include/kvm/kvm-help.h
create mode 100644 tools/kvm/kvm-cmd.c
create mode 100644 tools/kvm/kvm-help.c
diff --git a/tools/kvm/include/kvm/kvm-cmd.h b/tools/kvm/include/kvm/kvm-cmd.h
new file mode 100644
index 000..8d5fca5
--- /dev/null
+++ b/tools/kvm/include/kvm/kvm-cmd.h
@@ -0,0 +1,12 @@
+#ifndef __KVM_CMD_H__
+#define __KVM_CMD_H__
+
+struct cmd_struct {
+ const char *cmd;
+ int (*fn)(int, const char **, const char *);
+ int option;
+};
+
+int handle_command(struct cmd_struct *command, int argc, const char **argv);
+
+#endif
diff --git a/tools/kvm/include/kvm/kvm-help.h b/tools/kvm/include/kvm/kvm-help.h
new file mode 100644
index 000..2946743
--- /dev/null
+++ b/tools/kvm/include/kvm/kvm-help.h
@@ -0,0 +1,6 @@
+#ifndef __KVM_HELP_H__
+#define __KVM_HELP_H__
+
+int kvm_cmd_help(int argc, const char **argv, const char *prefix);
+
+#endif
diff --git a/tools/kvm/kvm-cmd.c b/tools/kvm/kvm-cmd.c
new file mode 100644
index 000..ef9a454
--- /dev/null
+++ b/tools/kvm/kvm-cmd.c
@@ -0,0 +1,55 @@
+#include
+#include
+#include
+
+#include
+
+/* user defined header files */
+#include
+
+/* kvm_get_command: Searches the command in an array of the commands and
+ returns a pointer to cmd_struct if a match is found.
+
+ Input parameters:
+ command: Array of possible commands. The last entry in the array must be
+NULL.
+ cmd: A string command to search in the array
+
+ Return Value:
+ NULL: If the cmd is not matched with any of the command in the command array
+ p: Pointer to cmd_struct of the matching command
+ */
+static struct cmd_struct *kvm_get_command(struct cmd_struct *command,
+ const char *cmd)
+{
+ struct cmd_struct *p = command;
+
+ while (p->cmd) {
+ if (!strcmp(p->cmd, cmd))
+ return p;
+ p++;
+ }
+ return NULL;
+}
+
+int handle_command(struct cmd_struct *command, int argc, const char **argv)
+{
+ struct cmd_struct *p;
+ const char *prefix = NULL;
+
+ if (!argv || !*argv) {
+ p = kvm_get_command(command, "help");
+ assert(p);
+ return p->fn(argc, argv, prefix);
+ }
+
+ p = kvm_get_command(command, argv[0]);
+ if (!p) {
+ p = kvm_get_command(command, "help");
+ assert(p);
+ p->fn(argc, argv, prefix);
+ return EINVAL;
+ }
+
+ return p->fn(argc - 1, &argv[1], prefix);
+}
diff --git a/tools/kvm/kvm-help.c b/tools/kvm/kvm-help.c
new file mode 100644
index 000..fd133a9
--- /dev/null
+++ b/tools/kvm/kvm-help.c
@@ -0,0 +1,43 @@
+#include
+#include
+
+/* user defined headers */
+#include
+
+#include
+#include
+
+
+const char kvm_usage_string[] =
+ "kvm [--version] [--help] COMMAND [ARGS]";
+
+const char kvm_more_info_string[] =
+ "See 'kvm help COMMAND' for more information on a specific command.";
+
+
+static void list_common_cmds_help(void)
+{
+ unsigned int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ if (longest < strlen(common_cmds[i].name))
+ longest = strlen(common_cmds[i].name);
+ }
+
+ puts(" The most commonly used kvm commands are:");
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ printf(" %-*s ", longest, common_cmds[i].name);
+ puts(common_cmds[i].help);
+ }
+}
+
+int kvm_cmd_help(int argc, const char **argv, const char *prefix)
+{
+ if (!argv || !*argv) {
+ printf("\n usage: %s\n\n", kvm_usage_string);
+ list_common_cmds_help();
+ printf("\n %s\n\n", kvm_more_info_string);
+ return 0;
+ }
+ return 0;
+}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 kvm tool: 1/4] Generating list of common kvm tool commands
- The Documentation/ directory will have a text file for each commmand. The
text file should contain the information about the command in manpage format.
- command-list.txt: is a list of common commands used with the kvm tool.
- util/generate-cmdlist.sh: is a shell script that uses command-list.txt and
text files in Documentation/ directory to generate the common-cmds.h file in
the include directory. The header file is furthur used to display a usage
messgae. Almost the entire script is copied from the tools/perf.
Signed-off-by: Prasad Joshi
---
tools/kvm/Documentation/kvm-run.txt | 54 +++
tools/kvm/command-list.txt |5 +++
tools/kvm/util/generate-cmdlist.sh | 24 +++
3 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 tools/kvm/Documentation/kvm-run.txt
create mode 100644 tools/kvm/command-list.txt
create mode 100755 tools/kvm/util/generate-cmdlist.sh
diff --git a/tools/kvm/Documentation/kvm-run.txt
b/tools/kvm/Documentation/kvm-run.txt
new file mode 100644
index 000..4288204
--- /dev/null
+++ b/tools/kvm/Documentation/kvm-run.txt
@@ -0,0 +1,54 @@
+kvm-run(1)
+
+
+NAME
+
+kvm-run - Start the virtual machine
+
+SYNOPSIS
+
+[verse]
+'kvm run' [-k | --kernel ]
+ [-d | --image ]
+
+DESCRIPTION
+---
+The command starts a virtual machine.
+
+OPTIONS
+---
+-m::
+--mem=::
+ Virtual machine memory size in MiB.
+
+-p::
+--params::
+ Additional kernel command line arguments.
+
+-i::
+--initrd=::
+ Initial RAM disk image.
+
+-k::
+--kernel=::
+The virtual machine kernel.
+-k
+--kvm-dev=::
+ KVM device file
+
+-d::
+--image=::
+ A disk image file.
+
+-s::
+--single-step:: Enable single stepping.
+
+-g::
+--ioport-debug:: Enable ioport debugging.
+
+-c::
+--enable-virtio-console:: Enable the virtual IO console
+
+SEE ALSO
+
+linkkvm:
diff --git a/tools/kvm/command-list.txt b/tools/kvm/command-list.txt
new file mode 100644
index 000..4eaf399
--- /dev/null
+++ b/tools/kvm/command-list.txt
@@ -0,0 +1,5 @@
+#
+# List of known perf commands.
+# command name category [deprecated] [common]
+#
+kvm-runmainporcelain common
diff --git a/tools/kvm/util/generate-cmdlist.sh
b/tools/kvm/util/generate-cmdlist.sh
new file mode 100755
index 000..c3fd172
--- /dev/null
+++ b/tools/kvm/util/generate-cmdlist.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+echo "/* Automatically generated by $0 */
+struct cmdname_help
+{
+char name[16];
+char help[80];
+};
+
+static struct cmdname_help common_cmds[] = {"
+
+sed -n 's/^kvm-\([^ \t]*\).*common/\1/p' command-list.txt |
+sort |
+while read cmd
+do
+# TODO following sed command should be fixed
+ sed -n '/^NAME/,/^kvm-'"$cmd"'/ {
+/NAME/d
+/--/d
+s/.*kvm-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
+p
+}' "Documentation/kvm-$cmd.txt"
+done
+echo "};"
--
1.7.1
--
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: [Qemu-devel] KVM call minutes for Apr 5
On Thu, 2011-04-07 at 11:03 +0100, Stefan Hajnoczi wrote: > On Tue, Apr 5, 2011 at 6:37 PM, Lucas Meneghel Rodrigues > wrote: > > Thanks for your detailed response! > > > On Tue, 2011-04-05 at 16:29 +0100, Stefan Hajnoczi wrote: > >> * Public notifications of breakage, qemu.git/master failures to > >> qemu-devel mailing list. > > > > ^ The challenge is to get enough data to determine what is a new > > breakage from a known issue, mainly. More related to have historical > > data from test results than anything else, IMO. > > I agree. Does kvm-autotest currently archive test results? It does. Our test layouts are currently evolving, and we are hoping to reach a very good and sane format. We are also thinking more about how to look at historical data and stablish regressions. > >> * A one-time contributor can get their code tested. No requirement to > >> set up a server because contributors may not have the resources. > > > > Coming back to the point that many colleagues made: We need a sort of > > 'make test' on the qemu trees that would fetch autotest and could setup > > basic tests that people could run, maybe suggest test sets... > > > > The problem I see is, getting guests up and running using configs that > > actually matter is not trivial (there are things such as ensuring that > > all auxiliary utilities are installed in a distro agnostic fashion, > > having bridges and DHCP server setup on possibly a disconnected work > > laptop, and stuff). > > > > So, having a 'no brains involved at all' setup is quite a challenge, > > suggestions welcome. Also, downloading isos, waiting for guests to > > install and run thorough tests won't be fast. So J. Random Developer > > might not bother to run tests even if we can provide a fool proof, > > perfectly automated setup, because it'd take a long time at first to get > > the tests run. This is also a challenge. > > I'm actually starting to think that there is no one-size-fits-all solution. > > Developers need "make check"-type unit tests for various QEMU > subsystems. kvm-autotest could also run these unit tests as part of > its execution. > > Then there are end-to-end acceptance tests. They simply require > storage, network, and time resources and there's no way around that. > These tests are more suited to centralized testing infrastructure that > periodically tests qemu.git. > > On the community call I was trying to see if there is a "lightweight" > version of kvm-autotest that could be merged into qemu.git. But now I > think that this isn't realistic and it would be better to grow unit > tests in qemu.git while covering it with kvm-autotest for acceptance > testing. The "make check" could check out autotest in the background and execute a very simplistic set of test, with pre-made small linux guests, very much as jenkins + buildbot does. If we can figure a sane, automated bridge + dnsmasq setup, then we can provide both the unittests and very simple and restricted guest tests. Need to think more. > >> Perhaps kvm-autotest is a good platform for the automated testing of > >> ARM TCG. Paul is CCed, I recently saw the Jenkins qemu build and boot > >> tests he has set up. Lucas, do you have ideas on how these efforts > >> can work together to bring testing to upstream QEMU? > >> http://validation.linaro.org/jenkins/job/qemu-boot-images/ > > > > I heard about jenkins before and it is indeed a nice project. What they > > do here, from what I could assess browsing at the webpage you provided > > is: > > > > 1) Build qemu.git every time there are commits > > 2) Boot pre-made 'pristine' images, one is a lenny arm image and the > > other is a linaro arm image. > > > > It is possible to do the same with kvm autotest, just a matter of not > > performing guest install tests and executing only the boot tests with > > pre-made images. What jenkins does here is a even quicker and shorter > > version of our sanity jobs. > > > > About how we can work together, I thought about some possibilities: > > > > 1) Modify the jenkins test step to execute a kvm autotest job after the > > build, with the stripped down test set. We might gain some extra debug > > info, that the current test step does not seem to provide > > 2) Do the normal test step and if that succeeds, trigger a kvm autotest > > job that does more comprehensive testing, such as migration, time drift, > > block layer, etc > > > > The funny thing is that KVM autotest has infrastructure to do the same > > as jenkins does, but jenkins is highly streamlined for the buildbot use > > case (continuous build and integration), and I see that as a very nice > > advantage. So I'd rather keep use jenkins and have kvm autotest plugged > > into it conveniently. > > That sounds good. I think the benefit of working together is that > different entities (Linaro, Red Hat, etc) can contribute QEMU tests > into a single place. That testing can then cover to both upstream and > downstream to prevent breakage. > > So k
[PATCH 2/2] kvm tools: Send SysRq-P to guest kernel on SIGQUIT
This patch makes SIGQUIT to the host hypervisor send 'SysRq-P' to the guest
kernel via 8250 serial console to make debugging stuck guests easier.
Cc: Asias He
Cc: Cyrill Gorcunov
Cc: Ingo Molnar
Signed-off-by: Pekka Enberg
---
tools/kvm/8250-serial.c | 33 +
tools/kvm/include/kvm/8250-serial.h |1 +
tools/kvm/main.c|1 +
3 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/8250-serial.c b/tools/kvm/8250-serial.c
index e92ff89..639afb2 100644
--- a/tools/kvm/8250-serial.c
+++ b/tools/kvm/8250-serial.c
@@ -53,6 +53,29 @@ static struct serial8250_device devices[] = {
},
};
+#define SYSRQ_PENDING_NONE 0
+#define SYSRQ_PENDING_BREAK1
+#define SYSRQ_PENDING_CMD 2
+
+static int sysrq_pending;
+
+static void serial8250__sysrq(struct kvm *self, struct serial8250_device *dev)
+{
+ switch (sysrq_pending) {
+ case SYSRQ_PENDING_BREAK:
+ dev->lsr|= UART_LSR_DR | UART_LSR_BI;
+
+ sysrq_pending = SYSRQ_PENDING_CMD;
+ break;
+ case SYSRQ_PENDING_CMD:
+ dev->rbr= 'p';
+ dev->lsr|= UART_LSR_DR;
+
+ sysrq_pending = SYSRQ_PENDING_NONE;
+ break;
+ }
+}
+
static void serial8250__receive(struct kvm *self, struct serial8250_device
*dev)
{
int c;
@@ -60,6 +83,11 @@ static void serial8250__receive(struct kvm *self, struct
serial8250_device *dev)
if (dev->lsr & UART_LSR_DR)
return;
+ if (sysrq_pending) {
+ serial8250__sysrq(self, dev);
+ return;
+ }
+
if (!term_readable(CONSOLE_8250))
return;
@@ -94,6 +122,11 @@ void serial8250__inject_interrupt(struct kvm *self)
}
}
+void serial8250__inject_sysrq(struct kvm *self)
+{
+ sysrq_pending = SYSRQ_PENDING_BREAK;
+}
+
static struct serial8250_device *find_device(uint16_t port)
{
unsigned int i;
diff --git a/tools/kvm/include/kvm/8250-serial.h
b/tools/kvm/include/kvm/8250-serial.h
index 73ed078..7a6d3f3 100644
--- a/tools/kvm/include/kvm/8250-serial.h
+++ b/tools/kvm/include/kvm/8250-serial.h
@@ -5,5 +5,6 @@ struct kvm;
void serial8250__init(struct kvm *kvm);
void serial8250__inject_interrupt(struct kvm *kvm);
+void serial8250__inject_sysrq(struct kvm *kvm);
#endif /* KVM__8250_SERIAL_H */
diff --git a/tools/kvm/main.c b/tools/kvm/main.c
index 6aa2534..d8f0c09 100644
--- a/tools/kvm/main.c
+++ b/tools/kvm/main.c
@@ -38,6 +38,7 @@ static void handle_sigint(int sig)
static void handle_sigquit(int sig)
{
+ serial8250__inject_sysrq(kvm);
kvm__show_registers(kvm);
kvm__show_code(kvm);
kvm__show_page_tables(kvm);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] kvm tools: Don't exit() on SIGQUIT
The point of SIGQUIT is to dump relevant information of a running guest, not to stop it. Cc: Asias He Cc: Cyrill Gorcunov Cc: Ingo Molnar Signed-off-by: Pekka Enberg --- tools/kvm/main.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/tools/kvm/main.c b/tools/kvm/main.c index 5bcefde..6aa2534 100644 --- a/tools/kvm/main.c +++ b/tools/kvm/main.c @@ -41,9 +41,6 @@ static void handle_sigquit(int sig) kvm__show_registers(kvm); kvm__show_code(kvm); kvm__show_page_tables(kvm); - kvm__delete(kvm); - - exit(1); } static char real_cmdline[2048]; -- 1.7.0.4 -- 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: [ANNOUNCE] Native Linux KVM tool
On Friday, April 8, 2011, Alexander Graf wrote: > > On 08.04.2011, at 12:42, Jan Kiszka wrote: > >> On 2011-04-08 11:32, Cyrill Gorcunov wrote: >>> It seems there is a misunderstanding. KVM-tool is quite far from been KVM >>> replacement (if ever). And what we're doing -- extremely tiny/small HV which >>> would help us to debug/test kernel code. >> >> I think your core team may have this vision, but my impression is that >> some people here think much further. > > I tend to agree. The core team seems to write this as a helping aid of > learning the platform and getting to know KVM. I really like that approach :). > > However, if it's meant to be a "toy" (and I don't mean this negatively in any > way), it really should be declared as such. Calling it "kvm" for example > would be a huge mistake in that case. > > Either way, I like the idea of having a second user space available for x86. > Even if it just means that it verifies that the documentation is correct :). > > > Alex > > If we manage to make kvm-tool mature i believe anyone will win in such case. The annonce stated clear the kvm-tool relation to qemu. Of course we have great planes tho :) -- 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: [ANNOUNCE] Native Linux KVM tool
On 08.04.2011, at 12:42, Jan Kiszka wrote: > On 2011-04-08 11:32, Cyrill Gorcunov wrote: >> It seems there is a misunderstanding. KVM-tool is quite far from been KVM >> replacement (if ever). And what we're doing -- extremely tiny/small HV which >> would help us to debug/test kernel code. > > I think your core team may have this vision, but my impression is that > some people here think much further. I tend to agree. The core team seems to write this as a helping aid of learning the platform and getting to know KVM. I really like that approach :). However, if it's meant to be a "toy" (and I don't mean this negatively in any way), it really should be declared as such. Calling it "kvm" for example would be a huge mistake in that case. Either way, I like the idea of having a second user space available for x86. Even if it just means that it verifies that the documentation is correct :). Alex -- 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: [ANNOUNCE] Native Linux KVM tool
On 2011-04-08 11:32, Cyrill Gorcunov wrote: > It seems there is a misunderstanding. KVM-tool is quite far from been KVM > replacement (if ever). And what we're doing -- extremely tiny/small HV which > would help us to debug/test kernel code. I think your core team may have this vision, but my impression is that some people here think much further. Also note that even for guest debugging some fairly essential features are missing yet. The gdbstub is among them and the most prominent one. > > So I personally think of two scenarios: > > 1) QEMU eventually get merged upstream and kvm-tool remains small and > tiny example of > how to do /dev/kvm ioctls with some positive (I hope) results. Or > maybe kvm-tool gets dropped > since nobody needs it, this is possible too of course. > > 2) kvm-tool silently sit in tools/kvm while qemu remains on separated > repo. Both go own > ways. Not a pleasant scenario but still possible. For me the separate tree thing is not that important as long as KVM developers continue to hack on both sides (which most of us do). > > And we don't consider kvm-tool as a qemu competitor by any means. It > simply different > weight categories. Long-term, IMHO, kvm-tool either has to cover at least one use case qemu is not interested in or it has to be noticeably better in one domain. Just being a small demo that has to be maintained _in_addition_ to qemu /wrt KVM ABI changes will make it suffer quickly. Right now x86 has reached a rather calm period in this regard, but PPC e.g. is about to enter the same stormy times we had with x86 in the past years. We've been through duplicate userland maintenance phase with qemu-kvm vs. upstream qemu for far too long, and it was a real pain (it still is, but the last duplicate bits should disappear before qemu-0.15). > > And of course we're glad to get any feedback (and positive and > especially negative). > Pointing out that SMP might be such a problem made us scratching the head ;) One big advantage of qemu is that it can nicely reproduce tricky concurrency issues (not all but many) as it provides true SMP support. We've successfully used this several times for debugging weird kernel and driver issues in the past 4 years. So I personally have no use case for kvm-tool that qemu(-kvm) wouldn't already solve, generally in a more advance way. That may explain my skepticism. :) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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: [ANNOUNCE] Native Linux KVM tool
On Fri, Apr 8, 2011 at 1:11 PM, Jan Kiszka wrote: > On 2011-04-08 10:27, Pekka Enberg wrote: >> Hi Jan, >> >> On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote: >>> I agree that it's easy to change 2kSomething LOC for this. But if you >>> now wait too long designing in essential features like SMP, a scalable >>> execution model, and - very important - portability (*), it can get >>> fairly painful to fix such architectural deficits later on. How long did >>> it take for Linux to overcome the BKL? QEMU is in the same unfortunate >>> position. >> >> Yup, and we're taking your feedback seriously (and are thankful for >> it!). We're hoping to look at SMP in the near future - help is >> appreciated! > > Honestly, I do not yet see a major advantage for us to invest here > instead of / in addition to continuing to improve QEMU. We've spend > quite some effort on the latter with IMO noteworthy results. Porting > over qemu-kvm to upstream was and still is among those efforts. We (*) > are "almost done". :) > > Just one example: Despite QEMU's current deficits, I just have add a > handful of (ad-hoc) patches to turn it into a (soft) real-time > hypervisor, and that also for certain non-Linux guests. Your approach is > yet man years of development and stabilization effort away from getting > close to such a level. > > Don't want to discourage you or other contributors. I wish you that this > approach can gather the critical mass and momentum to make it a real > alternative, at least for a subset of use cases. We will surely keep an > eye on it and re-assess its pros&cons as it progresses. > > Jan > > (*) the QEMU & KVM community > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > It seems there is a misunderstanding. KVM-tool is quite far from been KVM replacement (if ever). And what we're doing -- extremely tiny/small HV which would help us to debug/test kernel code. So I personally think of two scenarios: 1) QEMU eventually get merged upstream and kvm-tool remains small and tiny example of how to do /dev/kvm ioctls with some positive (I hope) results. Or maybe kvm-tool gets dropped since nobody needs it, this is possible too of course. 2) kvm-tool silently sit in tools/kvm while qemu remains on separated repo. Both go own ways. Not a pleasant scenario but still possible. And we don't consider kvm-tool as a qemu competitor by any means. It simply different weight categories. And of course we're glad to get any feedback (and positive and especially negative). Pointing out that SMP might be such a problem made us scratching the head ;) -- 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: [ANNOUNCE] Native Linux KVM tool
On 2011-04-08 10:27, Pekka Enberg wrote: > Hi Jan, > > On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote: >> I agree that it's easy to change 2kSomething LOC for this. But if you >> now wait too long designing in essential features like SMP, a scalable >> execution model, and - very important - portability (*), it can get >> fairly painful to fix such architectural deficits later on. How long did >> it take for Linux to overcome the BKL? QEMU is in the same unfortunate >> position. > > Yup, and we're taking your feedback seriously (and are thankful for > it!). We're hoping to look at SMP in the near future - help is > appreciated! Honestly, I do not yet see a major advantage for us to invest here instead of / in addition to continuing to improve QEMU. We've spend quite some effort on the latter with IMO noteworthy results. Porting over qemu-kvm to upstream was and still is among those efforts. We (*) are "almost done". :) Just one example: Despite QEMU's current deficits, I just have add a handful of (ad-hoc) patches to turn it into a (soft) real-time hypervisor, and that also for certain non-Linux guests. Your approach is yet man years of development and stabilization effort away from getting close to such a level. Don't want to discourage you or other contributors. I wish you that this approach can gather the critical mass and momentum to make it a real alternative, at least for a subset of use cases. We will surely keep an eye on it and re-assess its pros&cons as it progresses. Jan (*) the QEMU & KVM community -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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 v2 1/2] rbd: use the higher level librbd instead of just librados
On Mon, Mar 28, 2011 at 04:15:57PM -0700, Josh Durgin wrote: > librbd stacks on top of librados to provide access > to rbd images. > > Using librbd simplifies the qemu code, and allows > qemu to use new versions of the rbd format > with few (if any) changes. > > Signed-off-by: Josh Durgin > Signed-off-by: Yehuda Sadeh > --- > block/rbd.c | 785 > +++-- > block/rbd_types.h | 71 - > configure | 33 +-- > 3 files changed, 221 insertions(+), 668 deletions(-) > delete mode 100644 block/rbd_types.h Hi Josh, I have applied your patches onto qemu.git/master and am running ceph.git/master. Unfortunately qemu-iotests fails for me. Test 016 seems to hang in qemu-io -g -c write -P 66 128M 512 rbd:rbd/t.raw. I can reproduce this consistently. Here is the backtrace of the hung process (not consuming CPU, probably deadlocked): Thread 9 (Thread 0x7f9ded6d6700 (LWP 26049)): #0 0x7f9def41d16c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9dee676d9a in Wait (this=0x2723950) at ./common/Cond.h:46 #2 SimpleMessenger::dispatch_entry (this=0x2723950) at msg/SimpleMessenger.cc:362 #3 0x7f9dee66180c in SimpleMessenger::DispatchThread::entry (this=) at msg/SimpleMessenger.h:533 #4 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #5 0x7f9dee14d02d in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 8 (Thread 0x7f9deced5700 (LWP 26050)): #0 0x7f9def41d16c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9dee674fab in Wait (this=0x2723950) at ./common/Cond.h:46 #2 SimpleMessenger::reaper_entry (this=0x2723950) at msg/SimpleMessenger.cc:2251 #3 0x7f9dee6617ac in SimpleMessenger::ReaperThread::entry (this=0x2723d80) at msg/SimpleMessenger.h:485 #4 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #5 0x7f9dee14d02d in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 7 (Thread 0x7f9dec6d4700 (LWP 26051)): #0 0x7f9def41d4d9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9dee72187a in WaitUntil (this=0x2722c00) at common/Cond.h:60 #2 SafeTimer::timer_thread (this=0x2722c00) at common/Timer.cc:110 #3 0x7f9dee722d7d in SafeTimerThread::entry (this=) at common/Timer.cc:38 #4 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #5 0x7f9dee14d02d in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 6 (Thread 0x7f9df07ea700 (LWP 26052)): #0 0x7f9def41d16c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9dee67cae1 in Wait (this=0x2729890) at ./common/Cond.h:46 #2 SimpleMessenger::Pipe::writer (this=0x2729890) at msg/SimpleMessenger.cc:1746 #3 0x7f9dee66187d in SimpleMessenger::Pipe::Writer::entry (this=) at msg/SimpleMessenger.h:204 #4 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #5 0x7f9dee14d02d in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 5 (Thread 0x7f9debed3700 (LWP 26055)): #0 0x7f9dee142113 in poll () from /lib/libc.so.6 #1 0x7f9dee66d599 in tcp_read_wait (sd=, timeout=) at msg/tcp.cc:48 #2 0x7f9dee66e89b in tcp_read (sd=3, buf=, len=1, timeout=90) at msg/tcp.cc:25 #3 0x7f9dee67ffd2 in SimpleMessenger::Pipe::reader (this=0x2729890) at msg/SimpleMessenger.cc:1539 #4 0x7f9dee66185d in SimpleMessenger::Pipe::Reader::entry (this=) at msg/SimpleMessenger.h:196 #5 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #6 0x7f9dee14d02d in clone () from /lib/libc.so.6 #7 0x in ?? () Thread 4 (Thread 0x7f9debdd2700 (LWP 26056)): #0 0x7f9def41d4d9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9dee72187a in WaitUntil (this=0x2722e58) at common/Cond.h:60 #2 SafeTimer::timer_thread (this=0x2722e58) at common/Timer.cc:110 #3 0x7f9dee722d7d in SafeTimerThread::entry (this=) at common/Timer.cc:38 #4 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #5 0x7f9dee14d02d in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 3 (Thread 0x7f9deb2ce700 (LWP 26306)): #0 0x7f9def41d16c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9dee67cae1 in Wait (this=0x272f090) at ./common/Cond.h:46 #2 SimpleMessenger::Pipe::writer (this=0x272f090) at msg/SimpleMessenger.cc:1746 #3 0x7f9dee66187d in SimpleMessenger::Pipe::Writer::entry (this=) at msg/SimpleMessenger.h:204 #4 0x7f9def4188ba in start_thread () from /lib/libpthread.so.0 #5 0x7f9dee14d02d in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 2 (Thread 0x7f9deb3cf700 (LWP 26309)): #0 0x7f9dee142113 in poll () from /lib/libc.so.6 #1 0x7f9dee66d599 in tcp_read_wait (sd=, timeout=) at msg/tcp.cc:48 #2 0x7f9dee66e89b in tcp_read (sd=4, buf=, len=1, timeout=90) at msg/t
Re: [ANNOUNCE] Native Linux KVM tool
Hi Jan, On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote: > I agree that it's easy to change 2kSomething LOC for this. But if you > now wait too long designing in essential features like SMP, a scalable > execution model, and - very important - portability (*), it can get > fairly painful to fix such architectural deficits later on. How long did > it take for Linux to overcome the BKL? QEMU is in the same unfortunate > position. Yup, and we're taking your feedback seriously (and are thankful for it!). We're hoping to look at SMP in the near future - help is appreciated! Pekka -- 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: [ANNOUNCE] Native Linux KVM tool
On 2011-04-08 07:14, Pekka Enberg wrote: > Hi Anthony, > > On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori wrote: >> If someone was going to seriously go about doing something like this, a >> better approach would be to start with QEMU and remove anything non-x86 and >> all of the UI/command line/management bits and start there. >> >> There's nothing more I'd like to see than a viable alternative to QEMU but >> ignoring any of the architectural mistakes in QEMU and repeating them in a >> new project isn't going to get there. > > Hey, feel free to help out! ;-) > > I don't agree that a working 2500 LOC program is 'repeating the same > architectural mistakes' as QEMU. I hope you realize that we've gotten > here with just three part-time hackers working from their proverbial > basements. So what you call mistakes, we call features for the sake of > simplicity. > > I also don't agree with this sentiment that unless we have SMP, > migration, yadda yadda yadda, now, it's impossible to change that in > the future. It ignores the fact that this is exactly how the Linux > kernel evolved and the fact that we're aggressively trying to keep the > code size as small and tidy as possible so that changing things is as > easy as possible. I agree that it's easy to change 2kSomething LOC for this. But if you now wait too long designing in essential features like SMP, a scalable execution model, and - very important - portability (*), it can get fairly painful to fix such architectural deficits later on. How long did it take for Linux to overcome the BKL? QEMU is in the same unfortunate position. Jan (*) I would consider Anthony's idea to drop anything !=x86 a mistake given where KVM is moving to, today on PPC, tomorrow likely on ARM - just to name two examples. -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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: [ANNOUNCE] Native Linux KVM tool
> > I may get some interest in using this tool for my debugging/testing/ > > self-educational porpuses, but cannot know what I can do/expect. > > Heh, it's all pretty straight-forward. Fetch the sources from this tree: > > git clone git://github.com/penberg/linux-kvm.git > > Find something interesting to hack on and when you have something you > want integrated send patches to penb...@kernel.org and CC this list. > That's it! Thank you for your answer! Actually, I knew how to get the code because I am checking most of emails on this ML. What I wanted to know is what I can do with this tool in the future. But OK, I got it that nothing is strictly determined at the moment about what features can/should be integrated. Takuya > > In the long run, we hope to live in the main kernel tree under > tools/kvm and be part of the regular kernel release cycle. > >Pekka -- 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
