Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

[J. Mayer]

On Mon, 2007-10-15 at 20:45 +0300, Blue Swirl wrote:
> On 10/15/07, Blue Swirl <address@hidden> wrote:
> > On 10/15/07, J. Mayer <address@hidden> wrote:
> > > On Sun, 2007-10-14 at 15:59 +0300, Blue Swirl wrote:
> > > > On 10/14/07, J. Mayer <address@hidden> wrote:
> > > > > Here's an updated version of the patch against current CVS.
> > > > > This patches provides reverse-endian, little-endian and big-endian
> > > > > memory accessors, available with and without softmmu. It also provides
> > > > > an IO_MEM_REVERSE TLB flag to allow future support of per-page
> > > > > endianness control, which is required by some targets CPU emulations.
> > > > > Having reverse-endian memory accessors also make it possible to 
> > > > > optimise
> > > > > reverse-endian memory access when the target CPU has dedicated
> > > > > instructions. For now, it includes optimisations for the PowerPC 
> > > > > target.
> > > >
> > > > This breaks Sparc32 softmmu, I get a black screen. Your changes to
> > > > target-sparc and hw/sun4m.c look fine, so the problem could be in IO?
> > >
> > > Did it worked before my commits ? I may have done something wrong during
> > > the merge...
> > > I will do more checks and more tests...
> >
> > If I disable the IOSWAP code, black screen is gone. I think this is
> > logical: the io accessors return host CPU values, therefore no byte
> > swapping need to be performed.
> >
> > The attached version works for me.
> 
> This patch takes the reverse endian functions into use for Sparc.
> 
> I added hypervisor versions of the functions. This is getting a bit
> ugly, time for #include magic? Physical versions could be useful too.

My first reaction is to say that it seems pointless to define hypervisor
access routines when emulating user-mode only. It seems more likely to
me that any attempt to do such an access in user-mode code would raise a
privilege exception. If such an access is really possible for any
reason, I think you're right, it might be time to have a template
header, called the same way the softmmu_template currently is.
Then, I tried to go this way, adding a "nommu_header.h" and a
"nommu_template.h" files.
I also completed the API, replacing ldq with lduq and adding ldsq
accessors.
Here's the updated patch, including the Sparc specific reverse-endian
changes.
I did test PowerPC, PowerPC64, i386 softmmu cases and PowerPC linux-user
case. I also succesfully launched the Sparc, ARM and Coldfire tests
images available from the Qemu page. I did not succeed with Mips test
case, but the problems comes during the initialisation, before the
emulation starts, failing to load the initrd. It seems to me that the
problems come from the fact I'm running on a 64 bits host: it seems to
run OK when launch in 32 bits mode but not in 64 bits mode, using clean
CVS sources. I will check this and propose a fix, if needed.
There is still at least one bug in that patch: the reverse-endian I/O
case, in cpu_physical_memory_rw (exec.c) is not handled and is to be
fixed.

-- 
J. Mayer <address@hidden>
Never organized

softmmu_reverse_endian.diff
Description: Text Data