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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]