[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs
From: |
Christoffer Dall |
Subject: |
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs |
Date: |
Mon, 20 Jan 2014 11:19:19 -0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Jan 20, 2014 at 03:22:11PM +0100, Alexander Graf wrote:
>
> On 17.01.2014, at 19:52, Peter Maydell <address@hidden> wrote:
>
> > 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)
>
> Yes, I fully agree :).
>
Great, I'll prepare a patch for the KVM API documentation.
-Christoffer
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Alexander Graf, 2014/01/20
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs,
Christoffer Dall <=
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Anup Patel, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Alexander Graf, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Alexander Graf, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Alexander Graf, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Greg Kurz, 2014/01/23
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Anup Patel, 2014/01/22
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Christoffer Dall, 2014/01/23