qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM and variable-endianness guest CPUs


From: Alexander Graf
Subject: Re: [Qemu-devel] KVM and variable-endianness guest CPUs
Date: Mon, 20 Jan 2014 15:20:05 +0100

On 18.01.2014, at 11:15, Peter Maydell <address@hidden> wrote:

> On 18 January 2014 07:32, Alexander Graf <address@hidden> wrote:
>>> Am 18.01.2014 um 05:24 schrieb Christoffer Dall <address@hidden>:
>>>> On Fri, Jan 17, 2014 at 06:52:57PM +0000, Peter Maydell wrote:
>>>> 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]
>>> 
>>> I completely agree, given that it's too late to be set on always LE/BE,
>>> I think the natural choice is something that allows a user to cast the
>>> byte array to an appropriate pointer type and dereference it.
>>> 
>>> And I think we need to amend the KVM API docs to specify this.
>> 
>> I don't see the problem.
> 
> The problem is (a) the docs aren't clear about the semantics
> (b) people have picked behaviour that suited them
> to implement without documenting what it was.

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.

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.

> 
>> For ppc we always do mmio emulation
>> as if the cpu was big endian.
> 
> Even if the guest, the host kernel and QEMU in userspace are
> all little endian?
> 
> Also "mmio emulation as if the CPU was big endian"
> doesn't make sense -- MMIO emulation doesn't depend
> on CPU endianness.
> 
>> We've had an is_bigendian variable
>> for that since the very first versions.
> 
> Where? In the kernel? In QEMU? What does it control?

In KVM. Check out 
https://github.com/agraf/linux-2.6/commit/1c00e7c21e39e20be7b03b111d5ab90ce938f108


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]