From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-devel@nongnu.org,
"nicolas.sauzede" <nicolas.sauzede@laposte.net>
Subject: Re: [Qemu-devel] Get current env within io_handler ?
Date: Tue, 22 May 2012 00:06:25 +0200 [thread overview]
Message-ID: <20120521220625.GA20808@zapo> (raw)
In-Reply-To: <CAAu8pHt6UhnVsRNjxGKiV8KMHfcu_hUt6YjMhbSYS8ZMVD6SZQ@mail.gmail.com>
On Mon, May 21, 2012 at 06:40:38PM +0000, Blue Swirl wrote:
> On Mon, May 21, 2012 at 6:28 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 21 May 2012 19:08, Blue Swirl <blauwirbel@gmail.com> wrote:
> >> On Mon, May 21, 2012 at 10:36 AM, Peter Maydell
> >> <peter.maydell@linaro.org> wrote:
> >>> I think it would be nice to have this in upstream qemu; however adding
> >>> transaction properties to the IO interface would be quite tricky I
> >>> suspect...
> >>
> >> This is limited to CPU and CPU local bus devices (not generic like
> >> PCI), so there could be an out of band mechanism to get/set the
> >> additional data.
> >
> > What's your definition of "generic" here? AMBA isn't particularly
> > limited to CPU local bus devices either, really (for instance
> > the connection between a versatile express CPU daughterboard
> > and the motherboard includes an AMBA AXI bus).
>
> I'd expect that only AMBA devices (ARM specific) would care about the
> properties, while for example NE2k could not care less.
>
> >
> >> For example store in op_helper.c could use
> >> cpu_set_amba_properties(...) before the store and afterwards
> >> cpu_get_amba_reply(...).
> >
> > We really don't want to do two helper function calls for every
> > load or store! If you're going to implement them at all then
> > you need a more efficient implementation than that...
>
> How about lazy evaluation: generate the properties/evaluate reply only
> if the device wants them via
> device_get_properties()/device_set_reply(). Then the transaction
> overhead could be ignored by everyone if not needed.
Hi,
This party came up when evaluating the mem API. IMO, it would be nice
to have a way for the master (CPU, DMA or whatever) to be able to pass
attributes with accesses. Possibly also for the device to return
return codes (or error codes) as a result of the access.
The details may be bus specific (AMBA, OCP, etc) but the concept is
not. Unfortunately, I'm afraid it would involve quite a bit of changes to
the code again unless someone comes up with a smart way of doing it...
Cheers
next prev parent reply other threads:[~2012-05-21 22:06 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
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 [this message]
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=20120521220625.GA20808@zapo \
--to=edgar.iglesias@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=nicolas.sauzede@laposte.net \
--cc=peter.maydell@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.