[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] KVM and variable-endianness guest CPUs
From: |
Peter Maydell |
Subject: |
[Qemu-devel] KVM and variable-endianness guest CPUs |
Date: |
Fri, 17 Jan 2014 17:53:31 +0000 |
[This seemed like a good jumping off point for this question.]
On 16 January 2014 17:51, Alexander Graf <address@hidden> wrote:
> Am 16.01.2014 um 18:41 schrieb Peter Maydell <address@hidden>:
>> 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
- [Qemu-devel] KVM and variable-endianness guest CPUs,
Peter Maydell <=
Re: [Qemu-devel] KVM and variable-endianness guest CPUs, Alexander Graf, 2014/01/20