Re: [kvm-unit-tests PATCH v6 00/18] ppc64: initial drop

[Laurent Vivier <lvivier@redhat.com>]

On 26/02/2016 14:41, David Gibson wrote:
> On Fri, Feb 26, 2016 at 02:05:06PM +0100, Andrew Jones wrote:
>> On Fri, Feb 26, 2016 at 03:24:49PM +1100, David Gibson wrote:
>>> On Thu, Feb 25, 2016 at 04:10:44PM +0100, Laurent Vivier wrote:
>>>> Hi,
>>>>
>>>> based on Drew's work, I've written two small patches to add support of
>>>> ppc64le host and target.
>>>>
>>>> As Drew's series is not merged I don't send yet theses patches, but you
>>>> can find them here:
>>>>
>>>> https://github.com/vivier/kvm-unit-tests/commits/ppc64/endianness-v1
>>>>
>>>> 1- powerpc: allow to build big-endian binaries on little-endian host
>>>> 2- powerpc: select endianness
>>>>
>>>> Patch 2 allows to build and test ppc64le target.
>>>>
>>>> I don't know what to do about these two patches: should I wait Drew's
>>>> series is merged or should I send them now for review?
>>>
>>> I think post now.  Possibly we can even fold them into Drew's initial
>>> drop.
>>
>> That sounds good to me to. I can pick them up when I post v7.
>>
>>>
>>> Btw, we should know our endianness on entry, so I'm not sure we need
>>> the automagic FIXUP_ENDIAN stuff.  Though maybe it's still the easiest
>>> way.
>>
>> I looked at this a bit too and was under the impression that we're
>> always going to start in BE, so either the bootloader or the kernel
>> has to do the wrong endian magic to switch. Since the kernel will have
>> to know how to do it anyway, in order to deal with a return from an
>> rtas call, then I was thinking it'd be easiest to leave the bootloader
>> a simple BE-only branch, and then do the wrong endian stuff in
>> cstart64.S. It's quite possible I'm missing something though.
> 
> Sorry, I wasn't clear.  LE tests will need code to switch into LE mode
> (although for the special case of kvm-unit-tests you could potentially
> put that in the boot_rom.bin).
> 
> That particular FIX_ENDIAN code, however, uses some magic to work
> regardless of the endian mode on entry (it starts with an instruction
> that is harmless on one endian, and a short relative jump in the other
> endian).  Since we know the endian on entry, we shouldn't need that.

Yes, I'm currently reworking the code in this way.

Laurent