qemu-devel
[Top][All Lists]
Advanced

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

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


From: Blue Swirl
Subject: Re: [Qemu-devel] Get current env within io_handler ?
Date: Sat, 19 May 2012 07:13:43 +0000

On Wed, May 16, 2012 at 7:58 AM, nicolas.sauzede
<address@hidden> 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



reply via email to

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