[Top][All Lists]

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

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

From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] Get current env within io_handler ?
Date: Tue, 22 May 2012 00:06:25 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, May 21, 2012 at 06:40:38PM +0000, Blue Swirl wrote:
> On Mon, May 21, 2012 at 6:28 PM, Peter Maydell <address@hidden> wrote:
> > On 21 May 2012 19:08, Blue Swirl <address@hidden> wrote:
> >> On Mon, May 21, 2012 at 10:36 AM, Peter Maydell
> >> <address@hidden> 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.


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


reply via email to

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