On 05/26/2014 04:41 PM, Ben Hutchings wrote:
On Mon, 2014-05-26 at 16:14 -0300, Mauricio Faria de Oliveira wrote:
Hi Ben,
On 05/25/2014 09:49 PM, Ben Hutchings wrote:
[...]
The thing with ppc64el is that it's usually not available for most
people to start on, so that debootstrap --second-stage (for running
in qemu-kvm, at least) is quite a common scenario nowadays.
[...]
Can you not run the second stage using qemu-ppc64le-static (or whatever
it's called)?
No; the kernel doesn't handle the 2 different ABIs at once, nor the
exception handlers' endianness being changed constantly at runtime,
I believe.
This is due to a combination of kernel/ABI/endianness incompatibility.
I'll refer you to this short and clear post [1] about that. It's a
good explanation that's been around.
[...]
But what does that have to do with QEMU? Does a ppc64 kernel support
ppc64le executables just enough to fail without letting a userland
interpreter handle them? Or does QEMU wrongly assume that it can rely
on the kernel and hardware for most of the emulation?
Hey, apologies. I missed a few points about qemu userspace emulation.
Chatted w/ some guys on the topic, and learned a bit to answer.
>>> Can you not run the second stage using qemu-ppc64le-static (or whatever
>>> it's called)?
The answer for this question is 'not yet'. Probably soon, but not right
now.
There are patches for qemu linux-user in the works [1] for powerpc64le
and ELFv2, and it seems there's a still a few ones to go. (and the name
seems to be qemu-ppc64le/-static)
Before going further, let me just step back a bit to the patch which
originated the discussion:
So, the config options for pulling things as built-in (thus avoiding
the need for an initramfs for qemu/kvm) should be removed from file,
correct?
> But what does that have to do with QEMU? [...]
Hm, now I'd think nothing. I was wrong in my early assumptions/answers.
Just a bit of a related discussion (unrelated to my previous, wrong
answer):
There's a qemu preference/norm for 'one kernel abi - one qemu target'[2]
(It seems one reason is the implementation of syscalls interception
and emulation -- which is aware of host and target endianness at compile
time). And that's why there will be different 'qemu-ppc64(le)' binaries.
But that's just out of curiosity.
> [...] Does a ppc64 kernel support
> ppc64le executables just enough to fail without letting a userland
> interpreter handle them? [...]
Ah, I see the point. They're supported as usual (as you mentioned,
fail and let userland handle, i.e., binfmt_misc).
> Or does QEMU wrongly assume that it can rely
> on the kernel and hardware for most of the emulation?
No, qemu doesn't wrongly assume things. I did. :)
Thanks for the thought provoking questions.
[1] http://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg01394.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg01602.html
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5384d85c.3010...@linux.vnet.ibm.com
