All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf@ezchip.com>
To: Chen Gang S <gang.chen@sunrus.com.cn>,
	riku.voipio@iki.fi, Peter Maydell <peter.maydell@linaro.org>
Cc: "walt@tilera.com" <walt@tilera.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user.
Date: Wed, 11 Feb 2015 19:24:50 -0500	[thread overview]
Message-ID: <54DBF2D2.3000802@ezchip.com> (raw)
In-Reply-To: <54DBEFD3.1070609@sunrus.com.cn>

On 2/12/15 08:00, Chen Gang S wrote:
> After load elf64 tilegx binary for linux-user, the working flow reaches
> the first correct instruction postion "__start".

Congratulations on getting started.  I hope you have success with the emulation part.

> index f185dd0..d9e0dec 100755
> --- a/configure
> +++ b/configure
> @@ -5089,6 +5089,9 @@ case "$target_name" in
>       TARGET_BASE_ARCH=mips
>       echo "TARGET_ABI_MIPSN64=y" >> $config_target_mak
>     ;;
> +  tile)
> +    TARGET_ARCH=tile
> +  ;;

I would recommend using "tilegx" here and throughout since in principle "tile" includes both the old 32-bit tilepro architecture as well as the newer 64-bit tilegx architecture.

>   
> +#define EM_TILE      191 /* Tile */
> +#define EM_TILE_OLD  0x2597 /* Tile compat */

No need for EM_TILE_OLD - it never really got out into the wild.

Also, 191 is EM_TILEGX in <elf.h>, so you really should use the same name here, not EM_TILE.

> @@ -2012,6 +2035,7 @@ static void load_elf_interp(const char *filename, struct image_info *info,
>       }
>   
>       load_elf_image(filename, fd, info, NULL, bprm_buf);
> +
>       return;
>   
>    exit_perror:

Stray newline - you should proof read the diff to avoid stuff like this.

> +        env->regs[56] = regs->sn;
> +        env->regs[57] = regs->idn0;
> +        env->regs[58] = regs->idn1;
> +        env->regs[59] = regs->udn0;
> +        env->regs[60] = regs->udn1;
> +        env->regs[61] = regs->udn2;
> +        env->regs[62] = regs->udn3;
> +        env->regs[63] = regs->zero;

Registers from 56 to 63 aren't really worth emulating.  56 to 62 aren't real registers; they're just access to the on-chip networks. If you were to really emulate them for multichip support, you'd need a bunch of special support to understand message formats and header words and wormhole routing, etc, which is probably out of scope. Just ignoring them completely is probably safest for now.  And 63 just always reads as zero and discards writes.

> +++ b/linux-user/tile/syscall_nr.h
> @@ -0,0 +1,327 @@
> +#ifndef TILE_SYSCALL_NR
> +#define TILE_SYSCALL_NR
> +
> +/*
> + * Copy from linux kernel asm-generic/unistd.h, which tile uses.
> + *
> + * At present, do not support 32-bit (-m32) tilegx executable binary
> + */
> +#define TARGET_NR_io_setup                      0
> +#define TARGET_NR_io_destroy                    1
> +#define TARGET_NR_io_submit                     2
[...]

Isn't there a way to say "use the asm-generic syscalls"?  What does ARM64 do, for example?  They use the generic syscall list.

> [...]
> +#define TARGET_NR_bpf                           280
> +#define TARGET_NR_execveat                      281
> +
> +/* current tilegx Linux kernel do not want to support the macros below */
> +

Probably better not to define them, then look at fixing anything that breaks as a result.  Again, ARM64 will be the same.

Similar comments apply to the other headers that tile uses that are just asm-generic versions.  It probably makes sense to have a qemu framework for asm-generic as well.

Tilera did some work on a qemu port only intended to be used with KVM for virtualization, so it probably doesn't do you much good.  If you're interested, I can send you the diffs.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

  reply	other threads:[~2015-02-12  2:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  0:00 [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user Chen Gang S
2015-02-12  0:12 ` Chen Gang S
2015-02-12  0:24   ` Chris Metcalf [this message]
2015-02-12  3:32     ` Chen Gang S
2015-02-12  3:48       ` Chen Gang S
2015-02-12 22:32         ` Chris Metcalf
2015-02-13  4:03           ` Chen Gang S
2015-02-12 22:31       ` Chris Metcalf
2015-02-13  4:43         ` Chen Gang S
2015-02-13  4:56           ` Peter Maydell
2015-02-13  5:44             ` Chen Gang S
2015-02-13  5:43               ` Peter Maydell
2015-02-13  6:34                 ` Chen Gang S
2015-02-12  0:49 ` Peter Maydell
2015-02-12  2:53   ` Chen Gang S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54DBF2D2.3000802@ezchip.com \
    --to=cmetcalf@ezchip.com \
    --cc=gang.chen@sunrus.com.cn \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    --cc=walt@tilera.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.