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: Paul Brook
Subject: Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio
Date: Fri, 26 Nov 2010 23:47:45 +0000
User-agent: KMail/1.13.5 (Linux/2.6.36-trunk-amd64; KDE/4.4.5; x86_64; ; )

> > 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. :)

Many #ifdefs inconsistently scattered through all the device code have been 
replaced by a single #ifdef.

> 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.

Switching endianness of a CPU generally does not effect the endianness of the 
CPU/peripheral busses.  It makes the CPU byteswap accesses before they are 
seen by either memory or devices.

In theory it might be possible to avoid redundant byteswaps if you're really 
clever.  In practice you still have to handle the fact that your devices are a 
different endianness to RAM, so it probably doesn't gain you a whole lot.

Paul



reply via email to

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