qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Need some help in understanding qemu infrastructure and


From: Peter Maydell
Subject: Re: [Qemu-devel] Need some help in understanding qemu infrastructure and execution flow
Date: Mon, 22 Dec 2014 18:41:46 +0000

On 22 December 2014 at 17:05, Ronex Dicapriyo <address@hidden> wrote:
> [Ronex] Ok, As I can understand, QEMU is functional accurate, rather than
> cycle for fast simulation. But there must be some kind of reference clock,
> like say for example any timer device which raises an interrupt after couple
> of cycles (i.e after each 50ns it increments it timer counter register), How
> it can be implemented in QEMU, I could not understand what you are referring
> by host clock, are you pointing at the real-time clock of the host system
> where any qemu binary or executable runs (it sounds quite wierd to me ) ?

See include/qemu/timer.h for the descriptions of our
various clocks. Typically a timer will use QEMU_CLOCK_VIRTUAL,
which boils down to a call to get_clock(), which is just
a wrapper around clock_gettime(CLOCK_MONOTONIC, &ts).
That is, if you want a timer interrupt in 500ms time, you
get one in 500ms (host) time. In the meantime we'll run
the emulated CPU as fast as we can. (This all assumes you're
using QEMU's default mode; there is also a '-icount' command
line option which attempts to link together the clock with
a count of guest instructions executed in a way I don't
entirely understand, but which has the effect of making it
look a bit more like we execute a certain number of instructions
per second.)

The reason for this is that we're just trying to get a vaguely
plausible environment for a (typically Linux) guest to run.
It wants its timers to occur at the frequency it sets them
(so if you say "sleep 5" it really does sleep for 5 seconds),
wants as good performance as possible, and doesn't really
have serious timing dependencies between different devices.

Incidentally we would never implement a timer counter register
as "after 50ns increment the value" -- you emulate this by
simply working out what the correct value is at the point
when the guest would read it (ie "last known value + (time
since that last known value) / 50 ns"). Anything else is
horrifically inefficient.

I suggest you have a look at the source for a timer device
(they're all in hw/timer).

> Suppose I am directly accessing some X address of memory, which falls into
> the memory of device A, Now, if transaction doesn't involves CPU (may be
> using DMA), then how it calls the read/write methods associated with any
> device (for updating a device's register and carry out some specific
> functionality) ? Can you please suggest any memory management unit which is
> responsible for this ?

The MMU isn't relevant here, typically. DMA devices simply
use the APIs we have in QEMU for accessing guest physical memory
(which in turn end up decoding into RAM accesses or other
device accesses, etc). Try looking at the implementation of
a DMA controller in hw/dma/ or of some other device you know
that does DMA. Note that usually if the guest triggers a DMA
operation we'll just instantaneously do it rather than
trying to emulate the way the real hardware does this in the
background over a period of time.

If you get a DMA device A to write to another device B in
such a way that device B tries to DMA back to A then you'll
probably deadlock QEMU. You'll often deadlock real hardware if you
try that, too, so don't do that.

You almost certainly don't actually need to know the details
of how we figure out that an access to physical address X
is really a read from offset Y in device D -- that code just
works and you're better off focusing on the details of what
the APIs for implementing devices are.

>> 6) Debugging in QEMU
>
> Debugging of QEMU, or of the guest?
>
> How to debug any device code of QEMU, as well as some application running on
> Guest ?

Big topic. Short summary: we have some debug log options
(-d) for tracing some of QEMU's operations, and there is
of course gdb and putting printfs in your device code.
For debugging the guest we also have a gdb stub implementation.
There are no user-friendly facilities here but there is enough
to let you get the job done if you know what you're doing.

-- PMM



reply via email to

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