On 27/11/2017 17:02, Cornelia Huck wrote:
On Mon, 27 Nov 2017 16:53:04 +0100
Pierre Morel <pmo...@linux.vnet.ibm.com> wrote:
On 27/11/2017 16:30, Cornelia Huck wrote:
On Mon, 27 Nov 2017 16:24:08 +0100
Pierre Morel <pmo...@linux.vnet.ibm.com> wrote:
On 27/11/2017 15:34, Cornelia Huck wrote:
On Mon, 27 Nov 2017 12:02:55 +0100
Cornelia Huck <coh...@redhat.com> wrote:
On Mon, 27 Nov 2017 07:59:36 +0100
Thomas Huth <th...@redhat.com> 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
