KVM and variable-endianness guest CPUs

Peter Maydell
2014-01-17T17:53:52Z

[This seemed like a good jumping off point for this question.]

On 16 January 2014 17:51, Alexander Graf <agraf@suse.de> wrote:
> Am 16.01.2014 um 18:41 schrieb Peter Maydell <peter.maydell@linaro.org>:
>> Also see my remarks on the previous patch series suggesting
>> that we should look at this in a more holistic way than
>> just randomly fixing small bits of things. A good place
>> to start would be "what should the semantics of stl_p()
>> be for a QEMU where the CPU is currently operating with
>> a reversed endianness to the TARGET_WORDS_BIGENDIAN
>> setting?".
>
> That'd open a giant can of worms that I'd rather not open.

Yeah, but you kind of have to open that can, because stl_p()
is used in the code path for KVM MMIO accesses to devices.

Specifically, the KVM API says "here's a uint8_t[] byte
array and a length", and the current QEMU code treats that
as "this is a byte array written as if the guest CPU
(a) were in TARGET_WORDS_BIGENDIAN order and (b) wrote its
I/O access to this buffer rather than to the device".

The KVM API docs don't actually specify the endianness
semantics of the byte array, but I think that that really
needs to be nailed down. I can think of a couple of options:
* always LE
* always BE
[these first two are non-starters because they would
break either x86 or PPC existing code]
* always the endianness the guest is at the time
* always some arbitrary endianness based purely on the
endianness the KVM implementation used historically
* always the endianness of the host QEMU binary
* something else?

Any preferences? Current QEMU code basically assumes
"always the endianness of TARGET_WORDS_BIGENDIAN",
which is pretty random.

thanks
-- PMM