| Message ID | 292071c796105a489c3cfaab6aa52a9a89b6c5f0.1262645165.git.rth@twiddle.net |
|---|---|
| State | New |
| Headers | show |
On Jan 4, 2010, at 8:19 PM, Richard Henderson wrote: > The existing set of IPRs is totally irrelevant to user-mode emulation. > Indeed, they most are irrelevant to implementing kernel-mode emulation, > and would only be relevant to PAL-mode emulation, which I suspect that > no one will ever attempt. Interesting, that's the approach I used to emulate an es40 (ie full emulation of 21264). This had the advantage to be able to use the genuine ROM. Tristan.
On 01/06/2010 01:55 AM, Tristan Gingold wrote: >> The existing set of IPRs is totally irrelevant to user-mode emulation. >> Indeed, they most are irrelevant to implementing kernel-mode emulation, >> and would only be relevant to PAL-mode emulation, which I suspect that >> no one will ever attempt. > > Interesting, that's the approach I used to emulate an es40 (ie full emulation of 21264). > This had the advantage to be able to use the genuine ROM. Heh. Well, far be it for me to disuade. There's surely room for wanting to emulate at that level. However, since (1) ROMs other than the few supported by MILO are probably not redistributable and (2) I have the sense that generic kernel stuff would go faster emulating the PALcode specification, I think there's also a reason to do it that way too. All that said, there's currently nothing that distinguishes between anything but user-mode and system-mode. I would be delighted to see your es40 patches... r~
Am 06.01.2010 um 17:29 schrieb Richard Henderson: > since (1) ROMs other than the few supported by MILO are probably not > redistributable Tristan's trick here was to provide a way for the user to extract a non-distributable ROM. I fear the controversy of whether this should be in qemu-system-alpha or not kept the patch series from being committed. > I would be delighted to see your es40 patches... v4: http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg01541.html See also http://repo.or.cz/w/qemu/es40.git Since that series added devices necessary for system emulation I assume that parts of it need to be converted to the new qdev infrastructure. Andreas
On Jan 6, 2010, at 6:04 PM, Andreas Färber wrote: > > Am 06.01.2010 um 17:29 schrieb Richard Henderson: > >> since (1) ROMs other than the few supported by MILO are probably not redistributable > > Tristan's trick here was to provide a way for the user to extract a non-distributable ROM. I fear the controversy of whether this should be in qemu-system-alpha or not kept the patch series from being committed. No. This point was not discussed. It is always possible to use another ROM. I didn't continue this work because I hadn't had the time. The ROM is indeed an issue. MILO is a possible solution, but is not available on 21264 and can only boot linux. I am not even sure it is still supported. As I was mostly interested in Tru64 and VMS, I took the SRM way. Note that a SRM rescue files are available from hp.com site (which doesn't mean it is legal) and was already used in another es40 free emulator. I really don't plan to write a ROM for Alpha! Although for performance it can make sense to emulate PAL when the OS is running. >> I would be delighted to see your es40 patches... > > v4: http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg01541.html > > See also http://repo.or.cz/w/qemu/es40.git > > Since that series added devices necessary for system emulation I assume that parts of it need to be converted to the new qdev infrastructure. Right. This is not very recent. IIRC, I could reach a bash prompt, but I don't remember which kernel (2.2 or 2.6) I use. SRM was working, as well as AlphaBIOS. VMS bootloader crash very early. Maybe your alpha cpu fix could improve the situation. Tru64 crashed during boot. IOTLB was not supported in qemu. Windows crashed during boot too. Tristan.
Am 07.01.2010 um 12:54 schrieb Tristan Gingold: > > On Jan 6, 2010, at 6:04 PM, Andreas Färber wrote: > >> >> Am 06.01.2010 um 17:29 schrieb Richard Henderson: >> >>> since (1) ROMs other than the few supported by MILO are probably >>> not redistributable >> >> Tristan's trick here was to provide a way for the user to extract a >> non-distributable ROM. I fear the controversy of whether this >> should be in qemu-system-alpha or not kept the patch series from >> being committed. > > No. This point was not discussed. I was referring to this thread: http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg00795.html But I see now that it was discussed on v1, not v4. Anyway, part of the series was actually applied, just not the core es40 system emulation part. Andreas
diff --git a/linux-user/main.c b/linux-user/main.c index a0d8ce7..91e5009 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -3050,10 +3050,8 @@ int main(int argc, char **argv, char **envp) for(i = 0; i < 28; i++) { env->ir[i] = ((abi_ulong *)regs)[i]; } - env->ipr[IPR_USP] = regs->usp; - env->ir[30] = regs->usp; + env->ir[IR_SP] = regs->usp; env->pc = regs->pc; - env->unique = regs->unique; } #elif defined(TARGET_CRIS) { diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h index 4722415..3728d83 100644 --- a/target-alpha/cpu.h +++ b/target-alpha/cpu.h @@ -193,6 +193,11 @@ enum { /* Internal processor registers */ /* XXX: TOFIX: most of those registers are implementation dependant */ enum { +#if defined(CONFIG_USER_ONLY) + IPR_EXC_ADDR, + IPR_EXC_SUM, + IPR_EXC_MASK, +#else /* Ebox IPRs */ IPR_CC = 0xC0, /* 21264 */ IPR_CC_CTL = 0xC1, /* 21264 */ @@ -306,6 +311,7 @@ enum { IPR_VPTB, IPR_WHAMI, IPR_ALT_MODE, +#endif IPR_LAST, }; diff --git a/target-alpha/translate.c b/target-alpha/translate.c index 87813e7..515c8c7 100644 --- a/target-alpha/translate.c +++ b/target-alpha/translate.c @@ -2721,7 +2721,6 @@ static const struct cpu_def_t cpu_defs[] = { CPUAlphaState * cpu_alpha_init (const char *cpu_model) { CPUAlphaState *env; - uint64_t hwpcb; int implver, amask, i, max; env = qemu_mallocz(sizeof(CPUAlphaState)); @@ -2752,24 +2751,34 @@ CPUAlphaState * cpu_alpha_init (const char *cpu_model) | FPCR_UNFD | FPCR_INED | FPCR_DNOD)); #endif pal_init(env); + /* Initialize IPR */ - hwpcb = env->ipr[IPR_PCBB]; - env->ipr[IPR_ASN] = 0; - env->ipr[IPR_ASTEN] = 0; - env->ipr[IPR_ASTSR] = 0; - env->ipr[IPR_DATFX] = 0; - /* XXX: fix this */ - // env->ipr[IPR_ESP] = ldq_raw(hwpcb + 8); - // env->ipr[IPR_KSP] = ldq_raw(hwpcb + 0); - // env->ipr[IPR_SSP] = ldq_raw(hwpcb + 16); - // env->ipr[IPR_USP] = ldq_raw(hwpcb + 24); - env->ipr[IPR_FEN] = 0; - env->ipr[IPR_IPL] = 31; - env->ipr[IPR_MCES] = 0; - env->ipr[IPR_PERFMON] = 0; /* Implementation specific */ - // env->ipr[IPR_PTBR] = ldq_raw(hwpcb + 32); - env->ipr[IPR_SISR] = 0; - env->ipr[IPR_VIRBND] = -1ULL; +#if defined (CONFIG_USER_ONLY) + env->ipr[IPR_EXC_ADDR] = 0; + env->ipr[IPR_EXC_SUM] = 0; + env->ipr[IPR_EXC_MASK] = 0; +#else + { + uint64_t hwpcb; + hwpcb = env->ipr[IPR_PCBB]; + env->ipr[IPR_ASN] = 0; + env->ipr[IPR_ASTEN] = 0; + env->ipr[IPR_ASTSR] = 0; + env->ipr[IPR_DATFX] = 0; + /* XXX: fix this */ + // env->ipr[IPR_ESP] = ldq_raw(hwpcb + 8); + // env->ipr[IPR_KSP] = ldq_raw(hwpcb + 0); + // env->ipr[IPR_SSP] = ldq_raw(hwpcb + 16); + // env->ipr[IPR_USP] = ldq_raw(hwpcb + 24); + env->ipr[IPR_FEN] = 0; + env->ipr[IPR_IPL] = 31; + env->ipr[IPR_MCES] = 0; + env->ipr[IPR_PERFMON] = 0; /* Implementation specific */ + // env->ipr[IPR_PTBR] = ldq_raw(hwpcb + 32); + env->ipr[IPR_SISR] = 0; + env->ipr[IPR_VIRBND] = -1ULL; + } +#endif qemu_init_vcpu(env); return env;
The existing set of IPRs is totally irrelevant to user-mode emulation. Indeed, they most are irrelevant to implementing kernel-mode emulation, and would only be relevant to PAL-mode emulation, which I suspect that no one will ever attempt. Reducing the set of processor registers reduces the size of the CPU state. Signed-off-by: Richard Henderson <rth@twiddle.net> --- linux-user/main.c | 4 +--- target-alpha/cpu.h | 6 ++++++ target-alpha/translate.c | 45 +++++++++++++++++++++++++++------------------ 3 files changed, 34 insertions(+), 21 deletions(-)