All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] VFIO NATIVE_ENDIAN regions question
Date: Sun, 07 Sep 2014 22:35:18 +0200	[thread overview]
Message-ID: <540CC186.4020900@suse.de> (raw)
In-Reply-To: <1409971787-6153-1-git-send-email-aik@ozlabs.ru>



On 06.09.14 04:49, Alexey Kardashevskiy wrote:
> At the moment VFIO's BARs are NATIVE_ENDIAN. The idea is that since
> it does not parse BARs content and just provides transport, it should
> not do byte swaps, the guest does it anyway. That worked fine while
> the host was big-endian and it does not work when the host is little-endian.
> This happens because ./configure defines static macro TARGET_WORDS_BIGENDIAN
> for ppc64 and since there is no ppc64le - endianness of host and guest does
> not match and stl_p&co swaps bytes as shown below.
> 
> The proposed patch at the end of this mail fixes the issue for VFIO in
> any combination of host-guest, BE-LE (need to double check with BE host).
> However since I fail to grasp the idea of having statically defined
> TARGET_WORDS_BIGENDIAN, I assume I am missing something big here.
> 
> What would the correct fix be here? Thanks!
> 
> 
> 
> Breakpoint 9, vfio_bar_read (opaque=0x10de2e98, addr=0x6f4, size=0x4) at /home/alexey/p/qemu/hw/misc/vfio.c:1140
> 1140    {
> Missing separate debuginfos, use: zypper install glibc-debuginfo-2.19-15.1.ppc64le libgcc_s1-debuginfo-4.8.3+r212056-4.17.ppc64le libglib-2_0-0-debuginfo-2.38.2-5.8.ppc64le libgthread-2_0-0-debu
> ginfo-2.38.2-5.8.ppc64le libpcre1-debuginfo-8.33-3.253.ppc64le libpixman-1-0-debuginfo-0.32.6-1.1.ppc64le libstdc++6-debuginfo-4.8.3+r212056-4.17.ppc64le libz1-debuginfo-1.2.8-4.65.ppc64le
> (gdb) bt
> #0  vfio_bar_read (opaque=0x10de2e98, addr=0x6f4, size=0x4) at /home/alexey/p/qemu/hw/misc/vfio.c:1140
> #1  0x00000000100a4bd4 in memory_region_read_accessor (mr=0x10de2ea8, addr=0x6f4, value=0x3fffb77de320, size=0x4, shift=0x0, mask=0xffffffff) at /home/alexey/p/qemu/memory.c:410
> #2  0x00000000100a5000 in access_with_adjusted_size (addr=0x6f4, value=0x3fffb77de320, size=0x4, access_size_min=0x1, access_size_max=0x4, access=0x100a4b38 <memory_region_read_accessor>, mr=0x1
> 0de2ea8) at /home/alexey/p/qemu/memory.c:475
> #3  0x00000000100a84ac in memory_region_dispatch_read1 (mr=0x10de2ea8, addr=0x6f4, size=0x4) at /home/alexey/p/qemu/memory.c:1097
> #4  0x00000000100a85d8 in memory_region_dispatch_read (mr=0x10de2ea8, addr=0x6f4, pval=0x3fffb77de458, size=0x4) at /home/alexey/p/qemu/memory.c:1119
> #5  0x00000000100ace24 in io_mem_read (mr=0x10de2ea8, addr=0x6f4, pval=0x3fffb77de458, size=0x4) at /home/alexey/p/qemu/memory.c:1967
> #6  0x0000000010013bf8 in address_space_rw (as=0x1081d410 <address_space_memory>, addr=0x1a0b00006f4, buf=0x3fffb7f80028 "", len=0x4, is_write=0x0) at /home/alexey/p/qemu/exec.c:2076
> #7  0x0000000010013fa4 in cpu_physical_memory_rw (addr=0x1a0b00006f4, buf=0x3fffb7f80028 "", len=0x4, is_write=0x0) at /home/alexey/p/qemu/exec.c:2121
> #8  0x00000000100a015c in kvm_cpu_exec (cpu=0x3fffb77e0010) at /home/alexey/p/qemu/kvm-all.c:1770
> #9  0x000000001007ab18 in qemu_kvm_cpu_thread_fn (arg=0x3fffb77e0010) at /home/alexey/p/qemu/cpus.c:940
> #10 0x00003fffb7828a64 in start_thread () from /lib64/libpthread.so.0
> #11 0x00003fffb7993b00 in clone () from /lib64/libc.so.6
> (gdb) n
> 1141        VFIOBAR *bar = opaque;
> (gdb)
> 1148        uint64_t data = 0;
> (gdb)
> 1150        if (pread(bar->fd, &buf, size, bar->fd_offset + addr) != size) {
> (gdb)
> 1156        switch (size) {
> (gdb)
> 1164            data = buf.dword;
> (gdb)
> 1165            break;
> (gdb)
> 1171        if (addr == 0x6f4) {
> (gdb)
> 1172            printf("%s %u size=%d val=%lx\n", __func__, __LINE__, size, data);
> (gdb)
> vfio_bar_read 1172 size=4 val=4
> 1187        vfio_eoi(container_of(bar, VFIODevice, bars[bar->nr]));
> (gdb)
> 1189        return data;
> (gdb)
> 1190    }
> (gdb)
> memory_region_read_accessor (mr=0x10de2ea8, addr=0x6f4, value=0x3fffb77de320, size=0x4, shift=0x0, mask=0xffffffff) at /home/alexey/p/qemu/memory.c:411
> 411         trace_memory_region_ops_read(mr, addr, tmp, size);
> (gdb)
> 412         *value |= (tmp & mask) << shift;
> (gdb)
> 413     }
> (gdb)
> access_with_adjusted_size (addr=0x6f4, value=0x3fffb77de320, size=0x4, access_size_min=0x1, access_size_max=0x4, access=0x100a4b38 <memory_region_read_accessor>, mr=0x10de2ea8) at /home/alexey/p
> /qemu/memory.c:474
> 474             for (i = 0; i < size; i += access_size) {
> (gdb)
> 483     }
> (gdb)
> memory_region_dispatch_read1 (mr=0x10de2ea8, addr=0x6f4, size=0x4) at /home/alexey/p/qemu/memory.c:1106
> 1106        return data;
> (gdb)
> 1107    }
> (gdb)
> memory_region_dispatch_read (mr=0x10de2ea8, addr=0x6f4, pval=0x3fffb77de458, size=0x4) at /home/alexey/p/qemu/memory.c:1120
> 1120        adjust_endianness(mr, pval, size);
> (gdb) s
> adjust_endianness (mr=0x10de2ea8, data=0x3fffb77de458, size=0x4) at /home/alexey/p/qemu/memory.c:364
> 364     {
> (gdb) n
> 365         if (memory_region_wrong_endianness(mr)) {
> (gdb)
> 382     }
> (gdb)
> memory_region_dispatch_read (mr=0x10de2ea8, addr=0x6f4, pval=0x3fffb77de458, size=0x4) at /home/alexey/p/qemu/memory.c:1121
> 1121        return false;
> (gdb)
> 1122    }
> (gdb)
> io_mem_read (mr=0x10de2ea8, addr=0x6f4, pval=0x3fffb77de458, size=0x4) at /home/alexey/p/qemu/memory.c:1968
> 1968    }
> (gdb)
> address_space_rw (as=0x1081d410 <address_space_memory>, addr=0x1a0b00006f4, buf=0x3fffb7f80028 "", len=0x4, is_write=0x0) at /home/alexey/p/qemu/exec.c:2077
> 2077                        stl_p(buf, val);

How do you end up in stl_p on an mmio read? That sounds odd.


Alex

  parent reply	other threads:[~2014-09-07 20:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-06  2:49 [Qemu-devel] VFIO NATIVE_ENDIAN regions question Alexey Kardashevskiy
2014-09-07 16:06 ` Greg Kurz
2014-09-08  0:00   ` Alexey Kardashevskiy
2014-09-08  0:09     ` Alexey Kardashevskiy
2014-09-07 20:35 ` Alexander Graf [this message]
2014-09-08  0:06   ` Alexey Kardashevskiy
2014-09-08 12:04     ` Alexander Graf
2014-09-08 12:36       ` Alexey Kardashevskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540CC186.4020900@suse.de \
    --to=agraf@suse.de \
    --cc=afaerber@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.