[Qemu-devel] Get current env within io_handler ?

[Qemu-devel] Get current env within io_handler ?

[nicolas.sauzede]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Hi list,

I've implemented a way to link a qemu instance (arm) to a running TLM simulation.
That allows me to use qemu-system-arm as a minimal ARM ISS without any hardware device implemented within qemu,
all the peripherals are implemented in the TLM simulation.
This works by entering the TLM world when called back in the io_handlers.

This works fine for uniprocessor mode.
But 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;")

Thanks by advance,
NS.


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

[-- Attachment #2: Type: text/html, Size: 1108 bytes --]

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

[Andreas Färber]

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

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

[nicolas.sauzede]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

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 ?

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 ?


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

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

[-- Attachment #2: Type: text/html, Size: 3529 bytes --]

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

[Peter Maydell]

On 15 May 2012 16:31, nicolas.sauzede <nicolas.sauzede@laposte.net> wrote:
> 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);

Note that this interface is now obsolete and doesn't exist in current QEMU.
(The discussion below still applies to its replacement, though.)

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

In this situation, you can get the currrent processor via cpu_single_env.
An example is in arm_gic.c:gic_get_current_cpu(). However there are
some significant caveats:
 * cpu_single_env is only valid when your IO handler is called via
the memory read/write from a CPU. This is why exec.c is clearing it:
it means you're more likely to catch bugs where you try to look at
the CPU env when it's meaningless
 * many fields in the CPU env are only lazily updated, so they will
not be valid anyhow. The most obvious of these is the program counter,
but there are others (differs from architecture to architecture and
may change as qemu is developed over time)

So really the use cases are very limited. The two I know of that make
sense are:
 (1) to find the index of the current CPU; this is used by things like
the ARM GIC as a workaround for the fact that our memory transactions
don't include the CPU ID (which is what happens on hardware)
 (2) for extremely closely-coupled-to-the-CPU devices like the ARM
v7M NVIC which is really a part of the CPU which happens to have a
memory mapped interface.

-- PMM

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

[Andreas Färber]

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

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

[Anthony Liguori]

On 05/15/2012 10:31 AM, nicolas.sauzede wrote:
> 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);

Yes, it's entirely intentional to prevent io handlers from accessing CPUState.

For what you're doing, you need to hook more deeply into target-arm before the 
dispatch actually happens.

Regards,

Anthony Liguori

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

[nicolas.sauzede]

> Yes, it's entirely intentional to prevent io handlers from accessing CPUState.
> 
> For what you're doing, you need to hook more deeply into target-arm before the 
> dispatch actually happens.

Ok, but then I guess that this kind of hooks may be less generic than the traditional
"io_handler" I used for my qemu/TLM binding, right ?
Are there any example code showing such kind of hooks in qemu source ?
And is this method advisable, in term of maintenance, etc. ?
(what if we want to support multiple qemu targets, should we duplicate hooks code ?)

> Regards,
> 
> Anthony Liguori

Thanks for your support,
NS.


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

[nicolas.sauzede]

> First, please don't top-post and please don't use HTML emails.

Sorry about that.

> Yes, there is work towards getting rid of implicit AREG0 env. This will
> be leading towards removing the register-pinned AREG0.

Will this AREG0 removal be optional/configurable if the patches hit the mainstream ?

> So you should rather figure out why you want to tie emulation of devices
> to the CPU requesting it.

Well, for example, we have the issue where we need to know if the cpu that performs a hardware io is in priviledged/secure more, because some HW devices implemented in TLM requires such special flags on certain register accesses.
How can we know that access property, when called back into an "io_handler" ?

Also, I think about some specific IPs such as local timers and such, all seen at the same address by all the smp cpu, then how can we know what cpu number originated the io transaction ?

> Andreas
>

Thanks again,
NS.

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

[Blue Swirl]

On Wed, May 16, 2012 at 7:58 AM, nicolas.sauzede
<nicolas.sauzede@laposte.net> wrote:
>> First, please don't top-post and please don't use HTML emails.
>
> Sorry about that.
>
>> Yes, there is work towards getting rid of implicit AREG0 env. This will
>> be leading towards removing the register-pinned AREG0.
>
> Will this AREG0 removal be optional/configurable if the patches hit the mainstream ?

No. But it doesn't affect your case, AREG0 is only available to CPU
instruction emulation helpers, not devices. After AREG0 changes, CPU
state is still available to helpers via normal function call argument.

>
>> So you should rather figure out why you want to tie emulation of devices
>> to the CPU requesting it.
>
> Well, for example, we have the issue where we need to know if the cpu that performs a hardware io is in priviledged/secure more, because some HW devices implemented in TLM requires such special flags on certain register accesses.
> How can we know that access property, when called back into an "io_handler" ?

How does real HW do it? I don't think there is a bus that indicates
the CPU number to the device. I suppose the HW device is not really
external to the CPU but actually there is one device per each CPU
core. In that case, the modeling should be similar to for example x86
APIC or MIPS CPU timers (not very nicely implemented example, uses
obsolete constructs and does not conform to CODING_STYLE).

>
> Also, I think about some specific IPs such as local timers and such, all seen at the same address by all the smp cpu, then how can we know what cpu number originated the io transaction ?

For each CPU, a different physical memory view should be constructed,
with a different CPU specific device at this common address. I'm not
sure if memory API can handle this yet, but it would be useful for x86
APIC as well which in theory could have similar arrangement.

>
>> Andreas
>>
>
> Thanks again,
> NS.
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
> Je crée ma boîte mail www.laposte.net

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

[Peter Maydell]

On 19 May 2012 08:13, Blue Swirl <blauwirbel@gmail.com> wrote:
> nicolas.sauzede wrote:
>> Well, for example, we have the issue where we need to know if
>> the cpu that performs a hardware io is in priviledged/secure mode,
>> because some HW devices implemented in TLM requires such special
>> flags on certain register accesses.

> How does real HW do it? I don't think there is a bus that indicates
> the CPU number to the device.

The AMBA AXI bus includes attributes for:
 * secure/nonsecure world (used for TrustZone)
 * privileged/nonprivileged
 * instruction/data access
 * a transaction ID

The transaction ID typically encodes "which core in the
CPU made this memory transaction?". It's not always
meaningful, eg when caching intervenes, but for device
access you can use it. I'd tend to expect to see that in
testbench setups rather than the real world, though. Looking
straightforwardly at the protection attributes as Nicolas
suggests is much more standard.

>> Also, I think about some specific IPs such as local timers and
>> such, all seen at the same address by all the smp cpu, then how
>> can we know what cpu number originated the io transaction ?
>
> For each CPU, a different physical memory view should be constructed,
> with a different CPU specific device at this common address. I'm not
> sure if memory API can handle this yet, but it would be useful for x86
> APIC as well which in theory could have similar arrangement.

This is conceptually the nicest way to handle these, yes, but
I don't think we have the infrastructure for it just at the
moment...

-- PMM

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

[nicolas.sauzede]

Hi Peter, 

> Message du 19/05/12 11:39
> De : "Peter Maydell" 
> A : "Blue Swirl" 
> Copie à : "nicolas.sauzede" , qemu-devel@nongnu.org
> Objet : Re: [Qemu-devel] Get current env within io_handler ?
>
> On 19 May 2012 08:13, Blue Swirl wrote:
> > nicolas.sauzede wrote:
> >> Well, for example, we have the issue where we need to know if
> >> the cpu that performs a hardware io is in priviledged/secure mode,
> >> because some HW devices implemented in TLM requires such special
> >> flags on certain register accesses.
> 
> > How does real HW do it? I don't think there is a bus that indicates
> > the CPU number to the device.
> 
> The AMBA AXI bus includes attributes for:
> * secure/nonsecure world (used for TrustZone)
> * privileged/nonprivileged
> * instruction/data access
> * a transaction ID
> 
> The transaction ID typically encodes "which core in the
> CPU made this memory transaction?". It's not always
> meaningful, eg when caching intervenes, but for device
> access you can use it. I'd tend to expect to see that in
> testbench setups rather than the real world, though. Looking
> straightforwardly at the protection attributes as Nicolas
> suggests is much more standard.

Ok, so I guess that for now, we have to live with the lack of a way to actually
get those io transaction properties, right ?
Do you think it would be feasible to allow it the future ? (for now, I've done
some shortcuts and ugly hardcoding in my TLM prototype to make things work, but still..)

In fact, we encounter the same kind of issues regarding the "debug" property when doing
io transaction.
When eg: the gdb stub accesses io, it uses the function : cpu_memory_rw_debug()
to fetch bytes from the memory for debugging purposes, and the issue is that that "debug" property is lost when it eventually calls in turn the function cpu_physical_memory_rw(), that gets propagated to io handlers, which don't know if it is a regular "software" transaction (ie: initiated by the CPU executing the software), or if it is an artificial "debug" access by eg: the debugger.
The impact is that if the io range matches some specific io hardware register implemented in TLM that triggers side-effects (such as eg: an interrupt, a DMA transfer, whatever, etc..) then the hardware wimulation will not be accurate..

For the same, we currently employ a trick to propagate in a dirty way this "debug" flag to the io handler, but again, it would be nice to get it legally, like the secure/priviledged mode, etc..

Do you think this feature could be useful/legitimate in upstream qemu ?

> >> Also, I think about some specific IPs such as local timers and
> >> such, all seen at the same address by all the smp cpu, then how
> >> can we know what cpu number originated the io transaction ?
> >
> > For each CPU, a different physical memory view should be constructed,
> > with a different CPU specific device at this common address. I'm not
> > sure if memory API can handle this yet, but it would be useful for x86
> > APIC as well which in theory could have similar arrangement.
> 
> This is conceptually the nicest way to handle these, yes, but
> I don't think we have the infrastructure for it just at the
> moment...
> 
> -- PMM

Thanks for your support,
NS.


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

[Peter Maydell]

On 21 May 2012 08:21, nicolas.sauzede <nicolas.sauzede@laposte.net> wrote:
> Ok, so I guess that for now, we have to live with the lack of a way to actually
> get those io transaction properties, right ?
> Do you think it would be feasible to allow it the future ? (for now, I've done
> some shortcuts and ugly hardcoding in my TLM prototype to make things work, but still..)
>
> In fact, we encounter the same kind of issues regarding the "debug" property when doing
> io transaction.

> Do you think this feature could be useful/legitimate in upstream qemu ?

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

-- PMM

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

[Andreas Färber]

Am 21.05.2012 09:21, schrieb nicolas.sauzede:
> Hi Peter, 
> 
>> Message du 19/05/12 11:39
>> De : "Peter Maydell" 
>> A : "Blue Swirl" 
>> Copie à : "nicolas.sauzede" , qemu-devel@nongnu.org
>> Objet : Re: [Qemu-devel] Get current env within io_handler ?
>>
>> On 19 May 2012 08:13, Blue Swirl wrote:
>>> nicolas.sauzede wrote:
>>>> Well, for example, we have the issue where we need to know if
>>>> the cpu that performs a hardware io is in priviledged/secure mode,
>>>> because some HW devices implemented in TLM requires such special
>>>> flags on certain register accesses.
>>
>>> How does real HW do it? I don't think there is a bus that indicates
>>> the CPU number to the device.
>>
>> The AMBA AXI bus includes attributes for:
>> * secure/nonsecure world (used for TrustZone)
>> * privileged/nonprivileged
>> * instruction/data access
>> * a transaction ID
>>
>> The transaction ID typically encodes "which core in the
>> CPU made this memory transaction?". It's not always
>> meaningful, eg when caching intervenes, but for device
>> access you can use it. I'd tend to expect to see that in
>> testbench setups rather than the real world, though. Looking
>> straightforwardly at the protection attributes as Nicolas
>> suggests is much more standard.
> 
> Ok, so I guess that for now, we have to live with the lack of a way to actually
> get those io transaction properties, right ?
> Do you think it would be feasible to allow it the future ? (for now, I've done
> some shortcuts and ugly hardcoding in my TLM prototype to make things work, but still..)
[...]
> Do you think this feature could be useful/legitimate in upstream qemu ?

You might want to coordinate that with Edgar, he did a TLM integration
once. But I have no clue how close to master his fork is.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Blue Swirl]

On Mon, May 21, 2012 at 10:36 AM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 21 May 2012 08:21, nicolas.sauzede <nicolas.sauzede@laposte.net> wrote:
>> Ok, so I guess that for now, we have to live with the lack of a way to actually
>> get those io transaction properties, right ?
>> Do you think it would be feasible to allow it the future ? (for now, I've done
>> some shortcuts and ugly hardcoding in my TLM prototype to make things work, but still..)
>>
>> In fact, we encounter the same kind of issues regarding the "debug" property when doing
>> io transaction.
>
>> Do you think this feature could be useful/legitimate in upstream qemu ?
>
> 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. For example store in op_helper.c could use
cpu_set_amba_properties(...) before the store and afterwards
cpu_get_amba_reply(...). An AMBA device could do the counterpart with
device_get_amba_properties() and device_set_amba_reply(). A generic
device (like NE2k) would not care about the properties or replies.

>
> -- PMM

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

[Peter Maydell]

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

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

-- PMM

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

[Blue Swirl]

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.

>
> -- PMM

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

[Edgar E. Iglesias]

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