From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDxUc-0008QD-LW for qemu-devel@nongnu.org; Wed, 12 Oct 2011 08:01:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDxUX-0000Os-Kf for qemu-devel@nongnu.org; Wed, 12 Oct 2011 08:01:02 -0400 Received: from odin2.bull.net ([129.184.85.11]:43521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDxUX-0000Od-4q for qemu-devel@nongnu.org; Wed, 12 Oct 2011 08:00:57 -0400 Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id A9A571C4E3 for ; Wed, 12 Oct 2011 14:11:45 +0200 (CEST) Message-ID: <4E95818F.5050101@bull.net> Date: Wed, 12 Oct 2011 14:01:19 +0200 From: Francois WELLENREITER MIME-Version: 1.0 References: <4E956D20.20200@bull.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] PCI 64-bit BAR access with qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi Max, thank you for your answer. Actually, I hadn't confused. I already thought to your proposal but I found that it was a really ugly=20 solution (essentially because of the uint32_t to uint64_t silent=20 conversion). Isn't there any other (current or future) development that may fix it ? Fran=E7ois Le 12/10/2011 13:00, Max Filippov a =E9crit : >> I've read a few days ago that it was possible to emulate PCI devic= e with >> 64-bit BARs and have a real 64-bit memory access. >> Thus, I've created a virtual device named toto accessible through a 64= -bit >> BAR > You've probably confused an ability to locate BAR anywhere in 64-bit > address space (such BAR actually spans 2 consecutive PCI BAR registers > and has 100 in its 3 least significant bits) and an ability to access > BAR-mapped memory in 64 bit items. > > You obviously want the latter but currently it is not implemented, see = e.g. > > static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physad= dr, > target_ulong addr, > void *retaddr) > > definition in the softmmu_template.h. > > And it's quite simple to fix it, you only need to change > io_{read,write} in the softmmu_template.h and extend > io_mem_{read,write} loops in exec.c to 4 elements, taking care that > io_mem_{read,write}[3] can pass uint64_t. >