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?
