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

[nicolas.sauzede]

Sorry,
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);

 => 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.
 
But here, nothing is provided concerning the actual processor, right ?

Or do you mean that I can fetch current processor via the AREG0 ? Is there a macro (or example code) for that ?
 In some recent posts, I've seen that there are potential patches to actually remove AREG0 dependency, so will this method
be deprecated by those patches ?


Thanks for your support,
NS,

> > Message du 15/05/12 17:20
> > De : "Andreas Färber" 
> > A : "nicolas.sauzede" 
> > Copie à : address@hidden
> > Objet : Re: [Qemu-devel] Get current env within io_handler ?
> >
> > Am 15.05.2012 17:12, schrieb nicolas.sauzede:
> > > [...] when trying smp mode, I can't manage to retrieve the current env
> > > (ie: current smp processor number, registers, etc..),
> > > because it seems like the "cpu_single_env" variable is set to NULL
> > > explicitly in cpu-exec.c :
> > >      /* fail safe : never use cpu_single_env outside cpu_exec() */
> > >      cpu_single_env = NULL;
> > >      return ret;
> > >  }
> > > 
> > > Is this intentional ? Would it be very bad to get access to the current
> > > env in io_handler ? (it works if commenting out "cpu_single_env = NULL;")
> > 
> > I don't understand what io_handler you mean, but usually you have access
> > to an "env" variable, either passed explicitly or available pinned to
> > AREG0 register. cpu_single_env by contrary is most likely not the
> > solution you are looking for.
> > 
> > Andreas
> > 
> > -- 
> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> > 
> >