[Top][All Lists]
[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