From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O52as-0008Na-Si for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:01:50 -0400 Received: from [140.186.70.92] (port=33502 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O52ar-0008LU-FU for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:01:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O52ao-0004wA-QM for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:01:49 -0400 Received: from mail-pz0-f178.google.com ([209.85.222.178]:63535) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O52ao-0004vb-K2 for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:01:46 -0400 Received: by pzk8 with SMTP id 8so185637pzk.18 for ; Thu, 22 Apr 2010 13:01:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BD0A994.2090608@twiddle.net> References: <4BD0A994.2090608@twiddle.net> Date: Thu, 22 Apr 2010 23:01:43 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: agraf@suse.de, qemu-devel@nongnu.org, paul@codesourcery.com On 4/22/10, Richard Henderson wrote: > On 04/22/2010 12:38 PM, Blue Swirl wrote: > > Subpages are used when there are several devices on the same page. > > It's needed for at least Sparc32. > > > That's fine. > > > > Subwidth (with NULL) is used mainly to indicate that the device does > > not accept accesses in some access widths. Sparc32 and Sparc64 need > > this (or some other way to signal bus errors for bad access widths). > > > This is also fine. Although by using NULL all you'd get is a qemu > null pointer dereference; I suppose this might get caught and > translated to an cpu exception, but I think it would be preferable > long-term to be more explicit about this and fill in the entries > with a function that would explicitly raise the exception. Perhaps also the bus layer could do something here. > What this *does* confirm for me is that we don't need to support > multiple devices at the same address, differentiated by the size > of the reference. Which is something that the current subpage > implementation actually supports. Yes, I also agree it's a bit overkill. > I'll submit a patch to clean this up. > > > > In fact, many system devices on Sparc64 should only accept 64 bit > > accesses, but currently we can't enforce this. > > > Cool. This is something that should be fixed by the end result > of the driver interface re-design that pbrook and I have been > discussing on IRC. Interesting. Could you make a summary of the design for the benefit of the list?