Re: [Qemu-devel] Get current env within io_handler ?

[Peter Maydell]

On 15 May 2012 16:31, nicolas.sauzede <address@hidden> wrote:
> What I meant was the IO handlers we can register, when initializing an io
> memory area :
>
>     iomemtype = cpu_register_io_memory(tlm_qemu_readfn,
>                                        tlm_qemu_writefn, s,
>                                        DEVICE_NATIVE_ENDIAN);

Note that this interface is now obsolete and doesn't exist in current QEMU.
(The discussion below still applies to its replacement, though.)

> => tlm_qemu_readfn is declared like this :
> static CPUReadMemoryFunc * const tlm_qemu_readfn[] = {
>    tlm_qemu_read8,
>    tlm_qemu_read16,
>    tlm_qemu_read32
> };
>
> and tlm_qemu_read32 is :
> static uint32_t tlm_qemu_read32(void *opaque, target_phys_addr_t offset)
> {
>     uint32_t value;
>     tlm_qemu_read( opaque, offset, &value, sizeof( value));
>     return value;
> }
>
> What I mean is that the signature of what I call an "io_handler" offers an
> opaque which points to the State
> structure of the device, useful to know about the device area accessed, etc.

In this situation, you can get the currrent processor via cpu_single_env.
An example is in arm_gic.c:gic_get_current_cpu(). However there are
some significant caveats:
 * cpu_single_env is only valid when your IO handler is called via
the memory read/write from a CPU. This is why exec.c is clearing it:
it means you're more likely to catch bugs where you try to look at
the CPU env when it's meaningless
 * many fields in the CPU env are only lazily updated, so they will
not be valid anyhow. The most obvious of these is the program counter,
but there are others (differs from architecture to architecture and
may change as qemu is developed over time)

So really the use cases are very limited. The two I know of that make
sense are:
 (1) to find the index of the current CPU; this is used by things like
the ARM GIC as a workaround for the fact that our memory transactions
don't include the CPU ID (which is what happens on hardware)
 (2) for extremely closely-coupled-to-the-CPU devices like the ARM
v7M NVIC which is really a part of the CPU which happens to have a
memory mapped interface.

-- PMM