[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.
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
- Re: [Qemu-devel] Get current env within io_handler ?, (continued)
- Re: [Qemu-devel] Get current env within io_handler ?, Peter Maydell, 2012/05/15
- Re: [Qemu-devel] Get current env within io_handler ?, Andreas Färber, 2012/05/15
- Re: [Qemu-devel] Get current env within io_handler ?, nicolas.sauzede, 2012/05/16
- Re: [Qemu-devel] Get current env within io_handler ?, Blue Swirl, 2012/05/19
- Re: [Qemu-devel] Get current env within io_handler ?, Peter Maydell, 2012/05/19
- Re: [Qemu-devel] Get current env within io_handler ?, nicolas.sauzede, 2012/05/21
- Re: [Qemu-devel] Get current env within io_handler ?, Peter Maydell, 2012/05/21
- Re: [Qemu-devel] Get current env within io_handler ?, Blue Swirl, 2012/05/21
- Re: [Qemu-devel] Get current env within io_handler ?, Peter Maydell, 2012/05/21
- Re: [Qemu-devel] Get current env within io_handler ?, Blue Swirl, 2012/05/21
- Re: [Qemu-devel] Get current env within io_handler ?,
Edgar E. Iglesias <=
- Re: [Qemu-devel] Get current env within io_handler ?, Andreas Färber, 2012/05/21
- Re: [Qemu-devel] Get current env within io_handler ?, Anthony Liguori, 2012/05/15
- Re: [Qemu-devel] Get current env within io_handler ?, nicolas.sauzede, 2012/05/16