qemu-devel
[Top][All Lists]
Advanced

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

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


From: Andreas Färber
Subject: Re: [Qemu-devel] Get current env within io_handler ?
Date: Tue, 15 May 2012 18:34:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

Am 15.05.2012 17:31, schrieb 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 ?

First, please don't top-post and please don't use HTML emails.

I would strongly advise you to update to a more recent QEMU, we have
MemoryRegionOps in the meantime with different signature and scope.

Anyway, you are right, our device emulation is independent of the CPU
and is unaware of where it is being accessed from. We have a qtest
framework that tests devices without emulating a CPU at all.

> 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 ?

Yes, there is work towards getting rid of implicit AREG0 env. This will
be leading towards removing the register-pinned AREG0.

So you should rather figure out why you want to tie emulation of devices
to the CPU requesting it.

Andreas

> 
> 
> 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
>     >
>     > 
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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