[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KVM and variable-endianness guest CPUs
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] KVM and variable-endianness guest CPUs |
Date: |
Fri, 17 Jan 2014 18:52:57 +0000 |
On 17 January 2014 17:53, Peter Maydell <address@hidden> wrote:
> 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.
Having thought a little more about this, my opinion is:
* we should specify that the byte order of the mmio.data
array is host kernel endianness (ie same endianness
as the QEMU process itself) [this is what it actually
is, I think, for all the cases that work today]
* we should fix the code path in QEMU for handling
mmio.data which currently has the implicit assumption
that when using KVM TARGET_WORDS_BIGENDIAN is the same
as the QEMU host process endianness (because it's using
load/store functions which swap if TARGET_WORDS_BIGENDIAN
is different from HOST_WORDS_BIGENDIAN)
thanks
-- PMM
Re: [Qemu-devel] KVM and variable-endianness guest CPUs, Alexander Graf, 2014/01/20