From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLk09-000528-9f for qemu-devel@nongnu.org; Wed, 11 Feb 2015 21:59:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLk04-0007c5-MU for qemu-devel@nongnu.org; Wed, 11 Feb 2015 21:59:37 -0500 Received: from mail-am1on0633.outbound.protection.outlook.com ([2a01:111:f400:fe00::633]:6896 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLk04-0007bt-EF for qemu-devel@nongnu.org; Wed, 11 Feb 2015 21:59:32 -0500 Message-ID: <54DBF2D2.3000802@ezchip.com> Date: Wed, 11 Feb 2015 19:24:50 -0500 From: Chris Metcalf MIME-Version: 1.0 References: <54DBED38.4060005@sunrus.com.cn> <54DBEFD3.1070609@sunrus.com.cn> In-Reply-To: <54DBEFD3.1070609@sunrus.com.cn> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chen Gang S , riku.voipio@iki.fi, Peter Maydell Cc: "walt@tilera.com" , qemu-devel 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 , 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