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" , address@hidden
> 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