qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] Support for Cavium-Octeon specific instruct


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 2/2] Support for Cavium-Octeon specific instruction
Date: Wed, 13 Apr 2011 20:17:14 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Apr 13, 2011 at 12:26:01PM +0500, Khansa Butt wrote:
> We ported MIPS64 r2 user mode emulation. When a binary is given to
> qemu-mips64, our code first check whether it is Octeon binary or not if yes
> it  enable Octeon specific Instructions for. The following code snippet do
> this job:
> 
> >
> > > diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> > > index 2832a33..9399e44 100644
> > > --- a/linux-user/elfload.c
> > > +++ b/linux-user/elfload.c
> > > @@ -1662,6 +1662,11 @@ int load_elf_binary(struct linux_binprm * bprm,
> > > struct target_pt_regs * regs,
> > >         when we load the interpreter.  */
> > >      elf_ex = *(struct elfhdr *)bprm->buf;
> > >
> > > +#if defined(TARGET_MIPS64)
> > > +    if ((elf_ex.e_flags & EF_MIPS_MARCH) == E_MIPS_MACH_OCTEON) {
> > > +        info->elf_arch = 1;
> > > +    }
> > > +#endif
> > >
> > > +++ b/linux-user/main.c
> > > @@ -3348,6 +3348,11 @@ int main(int argc, char **argv, char **envp)
> > >          if (regs->cp0_epc & 1) {
> > >              env->hflags |= MIPS_HFLAG_M16;
> > >          }
> > > +#if defined(TARGET_MIPS64)
> > > +        if (info->elf_arch) {
> > > +            env->insn_flags |=  INSN_OCTEON;
> > > +        }
> > > +#endif
> > >      }
> >
>
> where we put elf_arch in image_info

I am not really sure about this name info->elf_arch, it is something
specific to octeon, but the name doesn't represent that. Also we
probably want a generic framework for changing a CPU to another one.

Note that in any case you can run qemu-mips64 with -cpu octeon if you
define an octeon CPU in translate_init.c.

> and INSN_OCTEON is in target_mips/mips-defs.h as follows
>   #define INSN_LOONGSON2E  0x20000000
>   #define INSN_LOONGSON2F  0x40000000
>   #define INSN_VR54XX 0x80000000
> +#define            INSN_OCTEON 0x10000000
> 
> Is this solution acceptable for you?

This part is clearly the way to go

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net



reply via email to

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