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

[Cornelia Huck]

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?