From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcPy6-00068V-P1 for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:02:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcPy5-00067f-8k for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:02:58 -0500 Received: from [199.232.76.173] (port=46632 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcPy4-00067W-Sk for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:02:56 -0500 Received: from mail-bw0-f171.google.com ([209.85.218.171]:60183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcPy4-0002g1-3a for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:02:56 -0500 Received: by bwz19 with SMTP id 19so144165bwz.34 for ; Wed, 25 Feb 2009 12:02:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <49A531AE.9080301@earthlink.net> References: <49A01839.3090402@earthlink.net> <49A3ECF9.1050507@earthlink.net> <49A486D1.3000305@earthlink.net> <49A4F272.3010005@redhat.com> <49A531AE.9080301@earthlink.net> Date: Wed, 25 Feb 2009 22:02:54 +0200 Message-ID: Subject: Re: [Qemu-devel] [RFC] 64 bit device I/O From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Reif Cc: qemu-devel@nongnu.org On 2/25/09, Robert Reif wrote: > Avi Kivity wrote: > > > Robert Reif wrote: > > > > > Blue Swirl wrote: > > > > > > > Would it be better to use a structure with four elements with correct > > > > types (including uint8/16_t) instead of the cast? This could also be > > > > limited to only cpu_register_io_memory64. > > > > > > > > > > > > > > > > > > > This is what I would prefer and is what the first version of this patch > > > that I submitted a year ago did: > http://landley.net/qemu/2008-01-01.html > > > > > > The problem is that every hardware driver would need to be changed and > > > some of them would need to be changed drastically because they use the > > > same functions for all three data sizes. No one seemed interested in > this > > > approach so I abandoned it. > > > > > > This approach while uglier requires no changes to the hardware drivers > > > unless they need 64 bit support so I hoped it would be better received. > > > > > > > You might try adding a struct-based 4-function interface, and implementing > the array-based 3-function interface on top of that. This way, no immediate > changes would be needed for devices, but we could change them incrementally > from the old interface to the new interface. > > > > > > > I just tried this by changing exec.c to use a structure internally but > still provide an array interface through the old interface and it's a real > nice cleanup until you have to deal with subpages. Changing the subpage > code over to a structure doesn't really improve it any. > > Why is the subpage code now saving so much redundant stuff compared to what > it initially started out as. Is it because that one VGA driver is messing > with the internals of QEMU? Also CPURead/WriteMemoryFunc structure could be read only, except for these VGA hacks.