qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/7] s390x/pci: factor out endia


From: Pierre Morel
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/7] s390x/pci: factor out endianess conversion
Date: Mon, 27 Nov 2017 17:40:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 27/11/2017 17:02, Cornelia Huck wrote:
On Mon, 27 Nov 2017 16:53:04 +0100
Pierre Morel <address@hidden> wrote:

On 27/11/2017 16:30, Cornelia Huck wrote:
On Mon, 27 Nov 2017 16:24:08 +0100
Pierre Morel <address@hidden> wrote:
On 27/11/2017 15:34, Cornelia Huck wrote:
On Mon, 27 Nov 2017 12:02:55 +0100
Cornelia Huck <address@hidden> wrote:
On Mon, 27 Nov 2017 07:59:36 +0100
Thomas Huth <address@hidden> wrote:
On 25.11.2017 14:49, Pierre Morel wrote:
On 24/11/2017 07:19, Yi Min Zhao wrote:


在 2017/11/23 下午8:18, Thomas Huth 写道:
On 23.11.2017 13:07, Yi Min Zhao wrote:
Another question, does 'cpu' in cpu_to_le**() or le**_to_cpu() mean the
host endianess?
Yes, the "cpu" in cpu_to_le or le_to_cpu means the host, indeed. It's
confusing :-/
If the answers to upper two questions are yes, we actually need handle
two cases.
1) For pcilg, we need to translate the data to little-endian, thus
cpu_to_le**().
2) For pcistg, we need to translate the data to host endianess, thus
le**_to_cpu().
I think we've got to byte-swap if the host is big endian (s390x), but
not if the host is little endian (x86 with TCG).

Here is my comprehension of this funny swapping:

- TCG for a BE guest and a le host swap bytes because if we do (register
& 0x01) in the zPCI interception code it must work what ever the
endianess is.

Uhhh, I might have missed that the value has already been byte-swapped
once by TCG for env->regs[r1] ...
Now I'm pretty much completely confused ... sorry for the noise if I was
wrong... I think it's best you ignore my comment for now (i.e. go with
bswapXX() instead of le_to_cpuXX()), and if we later wire up zPCI with
TCG, we still can fix this if necessary.

I'll try my current pci/tcg patches on LPAR with this (or a v4) on top.
If it works there (it doesn't yet on my laptop), we do have a
endianness issue... (unfortunately, the reverse isn't true.)

It does not look too bad: I can get a nice enP1p0s0 device from a
virtio-net-pci with my tcg patches on my laptop (with these patches as
well, of course). So, endianness is likely mostly fine.

On the Lpar and on the Laptop or only on the Lpar ?

Both :)

That's great! :)

Btw, lspci says

0001:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device
         Subsystem: Red Hat, Inc. Device 0001
         Physical Slot: 00000000
         Flags: bus master, fast devsel, latency 0
         I/O ports at <unassigned> [disabled]
         [virtual] Memory at 8001000000000000 (32-bit, non-prefetchable) 
[size=4K]
         Memory at 8002000000000000 (64-bit, prefetchable) [size=16K]
         Expansion ROM at <unassigned> [disabled] [size=256K]
         Capabilities: [98] MSI-X: Enable+ Count=3 Masked-
         Capabilities: [84] Vendor Specific Information: VirtIO: <unknown>
         Capabilities: [70] Vendor Specific Information: VirtIO: Notify
         Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
         Capabilities: [50] Vendor Specific Information: VirtIO: ISR
         Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
         Kernel driver in use: virtio-pci

Does that look reasonable to you?


Yes, I see no problem in what is listed.
Slot, memory, ROM, I/O port look reasonable to me.
The 4 Vendor Specific informations look like the VIRTIO subregions from BAR





--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany




reply via email to

[Prev in Thread] Current Thread [Next in Thread]