From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51091 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUyWV-0003lR-Od for qemu-devel@nongnu.org; Tue, 21 Dec 2010 04:28:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PUyWU-0003Fs-6c for qemu-devel@nongnu.org; Tue, 21 Dec 2010 04:28:47 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:47644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PUyWU-0003Fm-3t for qemu-devel@nongnu.org; Tue, 21 Dec 2010 04:28:46 -0500 Received: by qwk4 with SMTP id 4so3858243qwk.4 for ; Tue, 21 Dec 2010 01:28:45 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D0F9382.6050601@mc.net> References: <4D0CEAB0.9030706@mc.net> <4D0E5F16.3090905@mc.net> <4D0F9382.6050601@mc.net> From: Artyom Tarasenko Date: Tue, 21 Dec 2010 10:28:23 +0100 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bob Breuer Cc: Blue Swirl , =?ISO-8859-1?Q?Andreas_F=E4rber?= , QEMU Developers On Mon, Dec 20, 2010 at 6:33 PM, Bob Breuer wrote: > Artyom Tarasenko wrote: >> On Sun, Dec 19, 2010 at 8:37 PM, Bob Breuer wrote: >> >>> Andreas F=E4rber wrote: >>> >>>> Am 18.12.2010 um 19:53 schrieb Blue Swirl: >>>> >>>> >>>>> On Sat, Dec 18, 2010 at 5:09 PM, Bob Breuer 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. =A0So let'= s >>>>>> setup >>>>>> a flag (inspired by a previous patch from Blue Swirl) to identify le= dma >>>>>> from espdma, and map another 16 bytes of registers which return 0. >>>>>> >>>>>> Signed-off-by: Bob Breuer >>>>>> >>>> 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) >>>>>> =A0 =A0 DMAState *s =3D opaque; >>>>>> =A0 =A0 uint32_t saddr; >>>>>> >>>>>> + =A0 =A0if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) { >>>>>> + =A0 =A0 =A0 =A0return 0; /* extra mystery register(s) */ >>>>>> >>>> Wouldn't it be a good idea to trace these "mystery" reads... >>>> >>>> >>>>>> + =A0 =A0} >>>>>> =A0 =A0 saddr =3D (addr & DMA_MASK) >> 2; >>>>>> =A0 =A0 trace_sparc32_dma_mem_readl(addr, s->dmaregs[saddr]); >>>>>> =A0 =A0 return s->dmaregs[saddr]; >>>>>> @@ -175,6 +182,9 @@ static void dma_mem_writel(void *opaque, >>>>>> target_phys_addr_t addr, uint32_t val) >>>>>> =A0 =A0 DMAState *s =3D opaque; >>>>>> =A0 =A0 uint32_t saddr; >>>>>> >>>>>> + =A0 =A0if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) { >>>>>> + =A0 =A0 =A0 =A0return; /* 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. =A0How 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. =A0On 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.ht= ml >> >> 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. =A0If it's accessing a wrong > register because of a bug, then it may not matter what value is returned. I think the value is important, but the tests show that 0 is fine. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/