From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LztVV-0002Hf-2X for qemu-devel@nongnu.org; Fri, 01 May 2009 10:14:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LztVQ-0002Fx-IH for qemu-devel@nongnu.org; Fri, 01 May 2009 10:14:28 -0400 Received: from [199.232.76.173] (port=46012 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LztVQ-0002Fu-FS for qemu-devel@nongnu.org; Fri, 01 May 2009 10:14:24 -0400 Received: from mx20.gnu.org ([199.232.41.8]:8502) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LztVQ-0007yi-AS for qemu-devel@nongnu.org; Fri, 01 May 2009 10:14:24 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LztVP-0000iC-4x for qemu-devel@nongnu.org; Fri, 01 May 2009 10:14:23 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7 Date: Fri, 1 May 2009 15:14:20 +0100 References: <49EDB109.5010009@earthlink.net> <200905011303.50885.paul@codesourcery.com> <49FAFD36.5040609@earthlink.net> In-Reply-To: <49FAFD36.5040609@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905011514.21072.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Robert Reif > The right way to do this is to convert the whole tree at once > so we don't need the helper functions and two versions of > cpu_register_io_memory. > 95% of the hardware drivers could be trivially converted and > work fine. I think you're missing my point. It's the 95% of drivers that I don't want to have to "convert". I'm working on the assumption that devices that actually implement 64-bit transfers are the exception rather than the rule. So we have three options: 1) Omit the 64-bit handler for most devices. This will trigger the subwith code and associated overhead for no good reason[1]. 2) Implement a 64-bit handler for every single device. 90% of these are going to be identical trivial wrappers round the 32-bit function. Maybe 5% actually need 64-bit accesses, and 5% are broken because someone messed up a copy/paste. 3) Implement splitting of 64-bit accesses in generic code. Devices that actually care about 64-bit accesses can install a handler. Everything else indicates that it wants accesses split, either by a magic handler or a different registration function. Your current patch implements a broken version of (3), with a vague hope that we'll switch to (2) at some time in the future. I'm suggesting we implement (3) properly from the start. Paul [1] I still don't understand why the subwidth code exists, It's seems rather unlikely we'll have two different devices responding to different types of access the same address range. That's a separate argument though.