qemu-devel
[Top][All Lists]
Advanced

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

Re: Is qemu could be a "FSM" state machine if running on a "quiet and cl


From: John Snow
Subject: Re: Is qemu could be a "FSM" state machine if running on a "quiet and clean" host pc without random event input?
Date: Wed, 13 May 2020 19:22:12 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0


On 5/11/20 10:07 AM, tugouxp wrote:
> Hi folks:
>   i want to know about whether therr are limitations during qemu
> emulation systems, for exampe, did the regular bugs corener case cant be
> duplicated on qeme but exist on real boads?
> 

It's possible, yes. QEMU emulates instead of simulates. We do not try to
reproduce accurate cycle timings. There may be bugs that exist in real
hardware but don't reproduce with QEMU, or, of course, the other way around.

> why thing this is that , i have ever use hdl simulator (modsim and
> iverilog) and openrisc processor to emulate the linux and ucos running,
> and see the waveform of the simulateion process of the operations systems.
> i found an interesting things, if i take just the tick interrupt as the
> only testbech event source,the  kernel simulation waveform is identical
> duplicated again and again, which means i can predicate future behavior.
> 

Yeah, we are not operating on the verilog level for any of the hardware
we emulate.

> i think this something like qemu work principle and so want to know,
> whether the qemu has this limitation? is the simulation proces a "FSM" 
> that with definition output if the input event are all regular and
> without random?
> 

Well, if you only want determinism and not accuracy, it might be
possible, but I have to admit to you that I've never tried to instrument
or measure this. I assume there are many places where cycle
indeterminancy comes in from the host system.

And I trust x86 about as far as I can throw it.

I assume there are many barriers to this, but maybe folks who worked on
the replay debugger could give some more authoritative idea.


> thank you
> 




reply via email to

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