qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about timer interrupt handling in QEMU


From: Pavel Dovgalyuk
Subject: Re: Questions about timer interrupt handling in QEMU
Date: Mon, 15 Mar 2021 09:38:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

On 14.03.2021 12:04, Arnabjyoti Kalita wrote:
Hello all,

This is a continuation of some of the questions I had about the clock record-replay handling process in QEMU. My previous post is here -


https://www.mail-archive.com/qemu-discuss@nongnu.org/msg06231.html <https://www.mail-archive.com/qemu-discuss@nongnu.org/msg06231.html>


My experiment involves two steps. In the first step, I start QEMU in KVM mode, save the QEMU state and record the host clock values for some time. In the second step, I load the guest while starting QEMU in TCG mode. I replay the host clock values as and when they are accessed. By definition, the host clock is used by device models that simulate real time sources and is a source of non-determinism. Below are some of the questions I have -


- How do I ensure that the CPU configuration is exactly the same in KVM vs TCG modes? Can we use a generic CPU model, like "qemu64" and that ensures it? Will different CPU flags in both the modes affect it ?

I have no idea.

- I continuously see that the contents of memory are different when the guest tries to run a timer interrupt handler after it is loaded. Basically what happens is that I keep getting page faults when the hander tries to erase a timer from the rbtree. I seem to be replaying the host clock correctly, what else, might be wrong?


- Given the minimal replay requirements I have, is it enough if I only record the host clock timer ? Or do I need to record the other clock timer types in addition to it to make the guest behave correctly ?

Host clock replay is not enough.
Interrupts must be injected at the same time too.
QEMU does not process interrupts immediately, they may be postponed until the translation block ends. That is why record/replay includes additional synchronization for them.

Pavel Dovgalyuk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]