qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio
Date: Sat, 27 Nov 2010 00:06:01 +0100

On 27.11.2010, at 00:00, Andreas Färber wrote:

> Am 25.11.2010 um 08:35 schrieb Alexander Graf:
> 
>> The way we're currently modeling mmio is too simplified. We assume that
>> every device has the same endianness as the target CPU. In reality,
>> most devices are little endian (all PCI and ISA ones I'm aware of). Some
>> are big endian (special system devices) and a very little fraction is
>> target native endian (fw_cfg).
>> 
>> So instead of assuming every device to be native endianness, let's move
>> to a model where the device tells us which endianness it's in.
>> 
>> That way we can compile the devices only once and get rid of all the ugly
>> swap will be done by the underlying layer.
>> 
>> For the same of readability, this patch only introduces the helper framework
>> but doesn't allow the registering code to set its endianness yet.
>> 
>> Signed-off-by: Alexander Graf <address@hidden>
> 
>> ---
>> cpu-common.h |    4 ++
>> exec.c       |  122 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 126 insertions(+), 0 deletions(-)
>> 
>> diff --git a/cpu-common.h b/cpu-common.h
>> index a543b5d..839b236 100644
>> --- a/cpu-common.h
>> +++ b/cpu-common.h
>> @@ -20,6 +20,10 @@
>> 
>> #if !defined(CONFIG_USER_ONLY)
>> 
>> +#define DEVICE_NATIVE_ENDIAN  0
>> +#define DEVICE_BIG_ENDIAN     1
>> +#define DEVICE_LITTLE_ENDIAN  2
> 
> I believe some people around here voiced a preference for enums, to aid with 
> gdb debugging?

Yeah, I actually like enums better too :). Good point!

> 
>> diff --git a/exec.c b/exec.c
>> index db9ff55..f54a360 100644
>> --- a/exec.c
>> +++ b/exec.c
> 
>> @@ -3370,6 +3474,22 @@ static int cpu_register_io_memory_fixed(int io_index,
>>    }
>>    io_mem_opaque[io_index] = opaque;
>> 
>> +    switch (endian) {
>> +    case DEVICE_BIG_ENDIAN:
>> +#ifndef TARGET_WORDS_BIGENDIAN
>> +        swapendian_init(io_index);
>> +#endif
>> +        break;
> 
> So basically, you just moved the #ifdefs to another place. :) Shouldn't this 
> be dependent on the CPU state and determined at runtime? Thinking of MSR LE 
> bit on ppc. I guess QEMU doesn't support bi-endian ppc today, as does the 
> 970, but it would be nice to keep it in mind.

MSR_LE is the only case where runtime determination really makes sense. I'm not 
sure how that should be handled in the end. MSR_LE swizzles every memory 
access. Maybe it makes sense to just swap things inside of TCG code there.

Either way, I don't want to add any performance penalty to LE-on-LE (the 
default use case) and runtime checks on every MMIO are just too heavy :(.


Alex




reply via email to

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