qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: "nicolas.sauzede" <nicolas.sauzede@laposte.net>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Get current env within io_handler ?
Date: Tue, 15 May 2012 18:34:25 +0200	[thread overview]
Message-ID: <4FB28591.4090709@suse.de> (raw)
In-Reply-To: <27874590.608345.1337095907076.JavaMail.www@wwinf8306>

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 à : 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 = 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

  parent reply	other threads:[~2012-05-15 16:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15 15:12 [Qemu-devel] Get current env within io_handler ? nicolas.sauzede
2012-05-15 15:19 ` Andreas Färber
2012-05-15 15:31   ` nicolas.sauzede
2012-05-15 16:33     ` Peter Maydell
2012-05-15 16:34     ` Andreas Färber [this message]
2012-05-16  7:58       ` nicolas.sauzede
2012-05-19  7:13         ` Blue Swirl
2012-05-19  9:39           ` Peter Maydell
2012-05-21  7:21             ` nicolas.sauzede
2012-05-21 10:36               ` Peter Maydell
2012-05-21 18:08                 ` Blue Swirl
2012-05-21 18:28                   ` Peter Maydell
2012-05-21 18:40                     ` Blue Swirl
2012-05-21 22:06                       ` Edgar E. Iglesias
2012-05-21 11:57               ` Andreas Färber
2012-05-15 16:34     ` Anthony Liguori
2012-05-16  7:56       ` nicolas.sauzede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB28591.4090709@suse.de \
    --to=afaerber@suse.de \
    --cc=blauwirbel@gmail.com \
    --cc=nicolas.sauzede@laposte.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).