From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUJjP-0000tt-0C for qemu-devel@nongnu.org; Tue, 15 May 2012 11:32:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUJj4-00073c-60 for qemu-devel@nongnu.org; Tue, 15 May 2012 11:32:10 -0400 Received: from smtpout2.laposte.net ([193.253.67.227]:20754 helo=smtpout.laposte.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUJj3-00072s-QH for qemu-devel@nongnu.org; Tue, 15 May 2012 11:31:50 -0400 Date: Tue, 15 May 2012 17:31:47 +0200 From: "nicolas.sauzede" Message-ID: <27874590.608345.1337095907076.JavaMail.www@wwinf8306> In-Reply-To: <4FB27400.3010908@suse.de> References: <1512121653.606644.1337094765947.JavaMail.www@wwinf8306> <4FB27400.3010908@suse.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_608344_1756371636.1337095907074" Subject: Re: [Qemu-devel] Get current env within io_handler ? Reply-To: "nicolas.sauzede" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Andreas_F=C3=A4rber?= Cc: qemu-devel@nongnu.org ------=_Part_608344_1756371636.1337095907074 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, What I meant was the IO handlers we can register, when initializing an io m= emory area : =C2=A0=C2=A0=C2=A0 iomemtype =3D cpu_register_io_memory(tlm_qemu_readfn, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 tlm_qemu_writefn, s, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 DEVICE_NATIVE_ENDIAN); =3D> tlm_qemu_readfn is declared like this : static CPUReadMemoryFunc * const tlm_qemu_readfn[] =3D { =C2=A0=C2=A0 tlm_qemu_read8, =C2=A0=C2=A0 tlm_qemu_read16, =C2=A0=C2=A0 tlm_qemu_read32 }; and tlm_qemu_read32 is : static uint32_t tlm_qemu_read32(void *opaque, target_phys_addr_t offset) { =C2=A0=C2=A0=C2=A0 uint32_t value; =C2=A0=C2=A0=C2=A0 tlm_qemu_read( opaque, offset, &value, sizeof( value)); =C2=A0=C2=A0=C2=A0 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 actuall= y 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=C3=A4rber" > A : "nicolas.sauzede" > Copie =C3=A0 : qemu-devel@nongnu.org > 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 =3D 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 =3D NUL= L;") > > 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=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3= =BCrnberg > >=20 Une messagerie gratuite, garantie =C3=A0 vie et des services en plus, =C3= =A7a vous tente ? Je cr=C3=A9e ma bo=C3=AEte mail www.laposte.net ------=_Part_608344_1756371636.1337095907074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry,
What I meant wa= s the IO handlers we can register, when initializing an io memory area :
    iomemtype =3D cpu_register_io_memory(tlm_qemu_r= eadfn,
          &nb= sp;            =             &nb= sp;   tlm_qemu_writefn, s,
     &nb= sp;            =             &nb= sp;        DEVICE_NATIVE_ENDIAN);
<= br />

=3D> tlm_qemu_readfn is declared like this :
static CPURe= adMemoryFunc * const tlm_qemu_readfn[] =3D {
   tlm_qemu_rea= d8,
   tlm_qemu_read16,
   tlm_qemu_read32};

and tlm_qemu_read32 is :
static uint32_t tlm_qemu_rea= d32(void *opaque, target_phys_addr_t offset)
{
   = uint32_t value;
    tlm_qemu_read( opaque, offset, &am= p;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 de= vice, useful to know about the device area accessed, etc.

But h= ere, nothing is provided concerning the actual processor, right ?

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


Tha= nks for your support,
NS,

> Message du 15= /05/12 17:20
> De : "Andreas Färber"
> A : = "nicolas.sauzede"
> Copie à : qemu-devel@nongnu.o= rg
> 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 =3D NULL;
> > return ret;
> &g= t; }
> >
> > Is this intentional ? Would it be very= bad to get access to the current
> > env in io_handler ? (it wo= rks if commenting out "cpu_single_env =3D NULL;")
>
> I don't understand what io_handler you mean, but usually you have acc= ess
> to an "env" variable, either passed explicitly or a= vailable 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, Jennif= er Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
>
------=_Part_608344_1756371636.1337095907074--