qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers


From: Bob Breuer
Subject: Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers
Date: Mon, 20 Dec 2010 11:33:54 -0600
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

Artyom Tarasenko wrote:
> On Sun, Dec 19, 2010 at 8:37 PM, Bob Breuer <address@hidden> wrote:
>   
>> Andreas Färber wrote:
>>     
>>> Am 18.12.2010 um 19:53 schrieb Blue Swirl:
>>>
>>>       
>>>> On Sat, Dec 18, 2010 at 5:09 PM, Bob Breuer <address@hidden> wrote:
>>>>         
>>>>> ledma has 0x20 bytes of registers according to OBP, and at least
>>>>> Solaris9
>>>>> reads the 5th register which is beyond what we've mapped.  So let's
>>>>> setup
>>>>> a flag (inspired by a previous patch from Blue Swirl) to identify ledma
>>>>> from espdma, and map another 16 bytes of registers which return 0.
>>>>>
>>>>> Signed-off-by: Bob Breuer <address@hidden>
>>>>>           
>>> I'm not familar with that part of code but...
>>>
>>>       
>>>>> diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c
>>>>> index e78f025..56be8c8 100644
>>>>> --- a/hw/sparc32_dma.c
>>>>> +++ b/hw/sparc32_dma.c
>>>>>           
>>>>> @@ -165,6 +169,9 @@ static uint32_t dma_mem_readl(void *opaque,
>>>>> target_phys_addr_t addr)
>>>>>     DMAState *s = opaque;
>>>>>     uint32_t saddr;
>>>>>
>>>>> +    if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) {
>>>>> +        return 0; /* extra mystery register(s) */
>>>>>           
>>> Wouldn't it be a good idea to trace these "mystery" reads...
>>>
>>>       
>>>>> +    }
>>>>>     saddr = (addr & DMA_MASK) >> 2;
>>>>>     trace_sparc32_dma_mem_readl(addr, s->dmaregs[saddr]);
>>>>>     return s->dmaregs[saddr];
>>>>> @@ -175,6 +182,9 @@ static void dma_mem_writel(void *opaque,
>>>>> target_phys_addr_t addr, uint32_t val)
>>>>>     DMAState *s = opaque;
>>>>>     uint32_t saddr;
>>>>>
>>>>> +    if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) {
>>>>> +        return; /* extra mystery register(s) */
>>>>>           
>>> ...and writes? We return just before the tracepoints fire.
>>>
>>>       
>> Ok, I'll put together a patch to add the trace calls just before the
>> returns.  How about I also call it undocumented instead of mystery.
>> None of the BSD's or Linux know about or use anything beyond the 4
>> registers.
>>     
>
> I'd use "aliased" instead of mystery.  On a real SS-5:
>
> ok 78400020 20 spacel@ .
> a4240050
> ok 78400000 20 spacel@ .
> a4240050
> ok 78400024 20 spacel@ .
> fc004000
> ok 78400004 20 spacel@ .
> fc004000
>   
Verified that it also aliases on an SS-20.
> Addresses 0x7840002x are aliases for 0x7840000x. As well as
> 0x7840004x. And so on up to
> ok 787fffe4 20 spacel@ .
> fc004000
> 78800004 20 spacel@ .
> 0
>
> Or a real SS-20 ef0400000 is aliased up to ef37fffe0
>
> Fwiw I think it's a bug in the later Solaris versions:
> http://tyom.blogspot.com/2010/10/bug-in-all-solaris-versions-after-57.html
>
> On the bare metal it works because of address aliasing. If you want to
> emulate the hw precisely, the Blue's generic aliasing patch can be
> used here. The question is though do we want to do a generic aliasing
> for all the SBUS devices, or just in the single case(es) where we know
> is necessary.
>
> On the other hand Solaris seems to be fine with a 0 stub too.
>   
I'll send a patch to update the comments.  If it's accessing a wrong
register because of a bug, then it may not matter what value is returned.

Bob




reply via email to

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