[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Removing indeterminism in qemu execution
From: |
Lluís Vilanova |
Subject: |
Re: [Qemu-devel] Removing indeterminism in qemu execution |
Date: |
Mon, 23 Jan 2012 16:01:17 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
batuzovk writes:
>> I'm debugging an operating system with QEMU and I have a race condition in
>> the OS. The problem is that each time I run QEMU I get this error in a
>> different place, so it makes impossible for gdb to debug it. My plan is to
>> remove this indeterminism and be able to reproduce the same error in the
>> same place every time. To do that:
>>
>> * The test is automated (there is no user IO)
>> * I've passed the options "-rtc base=2006-06-17,clock=vm,driftfixone
>> -icount 2" to QEMU
>> * There is no use of KVM (the modules have been removed from the kernel)
>>
>> So even with that, in each execution I get a different error every time.
>> Do
>> you have any suggestions to make the execution identical each time is
>> being
>> run?
[...]
> Actually any (not only user) I/O can cause non-determinism: it is not
> known when data would be ready. The things became even more complicated if
> you took into account multi-threaded nature of QEMU. Threads communicate
> with each other and you can not predict context switches.
> AFAIK there is no easy guaranteed-to-work solution for your problem, but
> there are some hard ones (e.g. vmware retrace, though it is not based on
> QEMU). If your test case is really simple you can try disabling any
> multi-threading you can in QEMU and just hope for it to work.
AFAIK, you have four possible sources of guest indeterminism in QEMU:
* Interactions between multiple guest CPUs
Using the "-rtc base=2006-06-17,clock=vm" and "-icount 2" arguments, this
should be deterministic when ignoring interactions from external devices and
other QEMU threads.
* I/O devices raising interrupts
Using the "-rtc clock=vm" argument and *assuming* devices use the guest clock
to program interrupts, this should also be deterministic on the guest.
* I/O devices writing into memory the guest is concurrently reading
This is hard to solve when devices work in a thread separate from that of
guest CPUs, but I think it can be ignored.
* A host thread interrupting the guest CPU thread
This will force the guest CPU thread to recompute the number of guest
instructions until a guest CPU switch.
My understanding is that you're suggesting the problem Zeus is encountering is
the last one.
But then my question is, when is the guest CPU thread interrupted? That is,
ignoring incoming interrupts from external devices (covered in the 2nd point).
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth