On 20 January 2014 14:20, Alexander Graf <agraf@xxxxxxx> wrote: > I think I see the problem now. You're thinking about LE hosts, not LE guests. > > I think the only really sensible options would be to > > a) Always use a statically define target endianness (big for ppc) > b) Always use host endianness > Currently QEMU apparently implements a), but that can > easily be changed. Today we don't have kvm support for > ppc64le hosts yet. Yes; I would ideally like us be able to get rid of that statically defined target endianness eventually, so if we have the leeway to define the kernel<->userspace ABI in a way that doesn't care about the current guest CPU endianness (ie we haven't actually yet claimed support for reverse-endianness guests in a way that locks us into an unhelpful definition of the ABI) we should take it while we still can. Then the current QEMU restrictions boil down to "you can only use QEMU for KVM on a host kernel with the same endianness as QEMU's legacy TARGET_WORDS_BIGENDIAN setting for that CPU" (but such a QEMU can deal with guests whatever they do with the endianness control bits). > I personally prefer b). It's the natural thing to do for > a host interface to be in host endianness and it's exactly > what we expose for LE-on-BE systems with ppc already. Yes. Strictly speaking by "host endianness" here I guess we mean "the endianness of the kernel-to-userspace ABI", since it is at least in theory possible to have an LE kernel which runs BE userspace processes. thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
