From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDw8D-0001RJ-Qd for qemu-devel@nongnu.org; Wed, 12 Oct 2011 06:33:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDw8C-00055E-OK for qemu-devel@nongnu.org; Wed, 12 Oct 2011 06:33:49 -0400 Received: from odin2.bull.net ([129.184.85.11]:54212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDw8C-00054c-Bh for qemu-devel@nongnu.org; Wed, 12 Oct 2011 06:33:48 -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 112951C587 for ; Wed, 12 Oct 2011 12:44:35 +0200 (CEST) Message-ID: <4E956D20.20200@bull.net> Date: Wed, 12 Oct 2011 12:34:08 +0200 From: Francois WELLENREITER MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [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 there, I've read a few days ago that it was possible to emulate PCI device=20 with 64-bit BARs and have a real 64-bit memory access. Thus, I've created a virtual device named toto accessible through a=20 64-bit BAR ___ static const MemoryRegionOps bxi_common_mmio_ops =3D { .read =3D toto_mmio_read, .write =3D toto_mmio_write, .endianness =3D DEVICE_LITTLE_ENDIAN, .impl =3D { .min_access_size =3D 1, .max_access_size =3D 8, }, }; ___ memory_region_init_io(&d->mmio, &toto_mmio_ops, d, "toto-mmio", 0x1000); pci_register_bar(&d->dev, BAR_0, PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_6= 4, &d->mmio); ____ when I use in my driver pointers to "unsigned char", "unsigned short" or=20 "unsigned int", I can see that toto_mmio_read is called with increasing sizes. But that does not work at all with unsigned long long. In such a case, I always obtain two calls to toto_mmio_read with sizes=20 limited to 4. My understanding here is that a direct 64-bit memory access does not=20 work (but is composed of 2 32-bit accesses). Then, I've tried to understand why this happens and realized that=20 cpu_physical_memory_rw was always called for this memory region (for in=20 the old_mmio manner) : ___ (gdb) bt #0 toto_mmio_read (opaque=3D0x2bec2c0, addr=3D0, size=3D4) at=20 /home/workspace/qemu/hw/toto_hw.c:92 #1 0x00000000005f6d37 in memory_region_read_accessor (opaque=3D0x2bec738= ,=20 addr=3D0, value=3D0x7f9997ffec78, size=3D 4, shift=3D0, mask=3D4294967295) at /home/workspace/qemu/memory.c:23= 9 #2 0x00000000005f6ee0 in access_with_adjusted_size (addr=3D0,=20 value=3D0x7f9997ffec78, size=3D4, access_size_min=3D1, access_size_max=3D8, access=3D0x5f6cdf = ,=20 opaque=3D0x2bec738) at /home/workspace/qemu/memory.c:284 #3 0x00000000005f8909 in memory_region_read_thunk_n (_mr=3D0x2bec738,=20 addr=3D0, size=3D4) at /home/workspace/qemu/memory.c:824 #4 0x00000000005f8af1 in memory_region_read_thunk_l (mr=3D0x2bec738, add= r=3D0) at /home/workspace/qemu/memory.c:867 #5 0x00000000005c8f69 in cpu_physical_memory_rw (addr=3D3892314112,=20 buf=3D0x7f999c5d0028 "\320\b", len=3D8, is_write=3D0) at /home/workspace/qemu/exec.c:3965 #6 0x00000000005ecfa1 in kvm_cpu_exec (env=3D0x238ee10) at=20 /home/workspace/qemu/kvm-all.c:985 #7 0x00000000005bf1fb in qemu_kvm_cpu_thread_fn (arg=3D0x238ee10) at=20 /home/workspace/qemu/cpus.c:661 #8 0x00000034dfc077e1 in start_thread () from /lib64/libpthread.so.0 #9 0x00000034df4e68ed in clone () from /lib64/libc.so.6 ____ Did I miss anything ? Is it a real defect ? Are there developments still planned to allow a direct 64-bit access ? Thanks for any help, Fran=E7ois