thank you for your reply.I understand. Also I want to know how to make a delay in qemu. For example, when I send a UART data, there is a certain time interval from setting the register to when the data is sent. Most of this time does not affect the simulation effect, but some guest firmware will execute errors when there is no such delay. This is a comparison. Few, but it does exist. My question is, if I really want to add such a delay, how to do it. For example, in USART, can I set a callback for sending completion, or add some delays that will not cause qemu to freeze. Peter Maydell 于2021年9月7日周二 下午8:20写道: > On Tue, 7 Sept 2021 at 12:28, Duo jia wrote: > > > > In the controller, QEMUTimer will be used in the implementation of timer > simulation. > > > > I wrote an auto-loading timer with a period of 1ms and the clock source > used is QEMU_CLOCK_VIRTUAL. But it doesn't seem to be very accurate, > because the actual time after I accumulated it to 500 times took about > 700ms. > > It depends on how you use it. Generally the actual firing will not happen > exactly on the specified mark. So if your implementation is "set clock > for 1ms in the future; when it fires, set for 1ms in the future again" > that is likely to be inaccurate. If you implement it as "set clock for > 1ms in the future; when it fires, set for 1ms after the time when it > should have fired" it will probably be better. > > In particular, if the semantics of your timer fit the ptimer API > (which can implement oneshot and periodic timers) then I would recommend > using that instead of a raw QEMUTimer; it deals with a lot of these > fiddly details for you. > > -- PMM >