Application of QEMUTimer in short timing.

Application of QEMUTimer in short timing.

[Duo jia]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

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.

I think qemu's code will consume some time, is it true?


thank you ~

[-- Attachment #2: Type: text/html, Size: 456 bytes --]

Re: Application of QEMUTimer in short timing.

[Peter Maydell]

On Tue, 7 Sept 2021 at 12:28, Duo jia <jiaduo19920301@gmail.com> 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

Re: Application of QEMUTimer in short timing.

[Duo jia]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

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 <peter.maydell@linaro.org> 于2021年9月7日周二 下午8:20写道：

> On Tue, 7 Sept 2021 at 12:28, Duo jia <jiaduo19920301@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

Re: Application of QEMUTimer in short timing.

[Peter Maydell]

On Wed, 8 Sept 2021 at 03:50, Duo jia <jiaduo19920301@gmail.com> wrote:
> 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.

You can do this kind of thing with an additional timer.
Look at hw/char/cadenc_uart.c and its handling of char_tx_time
for an example. In that case it is (despite the name)
modelling slow data receive, not slow data transmit, but
the basic idea is the same.

As you say, though, very little guest code really cares about
UART character timings (and the guest code that does is probably
buggy strictly speaking). So if I were you I would put "model
delays in UART timings" very low on your priority list...

-- PMM

Re: Application of QEMUTimer in short timing.

[Duo jia]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

Got it.

Peter Maydell <peter.maydell@linaro.org> 于2021年9月8日周三 下午5:47写道：

> On Wed, 8 Sept 2021 at 03:50, Duo jia <jiaduo19920301@gmail.com> wrote:
> > 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.
>
> You can do this kind of thing with an additional timer.
> Look at hw/char/cadenc_uart.c and its handling of char_tx_time
> for an example. In that case it is (despite the name)
> modelling slow data receive, not slow data transmit, but
> the basic idea is the same.
>
> As you say, though, very little guest code really cares about
> UART character timings (and the guest code that does is probably
> buggy strictly speaking). So if I were you I would put "model
> delays in UART timings" very low on your priority list...
>
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 1700 bytes --]