From: Fabiano Rosas <farosas@linux.ibm.com>
To: "Cédric Le Goater" <clg@kaod.org>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, danielhb413@gmail.com, mario@locati.it
Subject: Re: [PATCH] target/ppc: Fix e6500 boot
Date: Mon, 13 Dec 2021 11:59:06 -0300 [thread overview]
Message-ID: <87o85kzh39.fsf@linux.ibm.com> (raw)
In-Reply-To: <f79d58b2-ad6d-2f85-b0d5-3d9db65f07dd@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> On 12/13/21 14:35, Fabiano Rosas wrote:
>> When Altivec support was added to the e6500 kernel in 2012[1], the
>> QEMU code was not changed, so we don't register the VPU/VPUA
>> exceptions for the e6500:
>>
>> qemu: fatal: Raised an exception without defined vector 73
>>
>> Note that the error message says 73, instead of 32, which is the IVOR
>> for VPU. This is because QEMU knows only knows about the VPU interrupt
>> for the 7400s. In theory, we should not be raising _that_ VPU
>> interrupt, but instead another one specific for the e6500.
>>
>> We unfortunately cannot register e6500-specific VPU/VPUA interrupts
>> because the SPEU/EFPDI interrupts also use IVOR32/33. These are
>> present only in the e500v1/2 versions. From the user manual:
>>
>> e500v1, e500v2: only SPEU/EFPDI/EFPRI
>> e500mc, e5500: no SPEU/EFPDI/EFPRI/VPU/VPUA
>> e6500: only VPU/VPUA
>>
>> So I'm leaving IVOR32/33 as SPEU/EFPDI, but altering the dispatch code
>> to convert the VPU #73 to a #32 when we're in the e6500. Since the
>> handling for SPEU and VPU is the same this is the only change that's
>> needed. The EFPDI is not implemented and will cause an abort. I don't
>> think it worth it changing the error message to take VPUA into
>> consideration, so I'm not changing anything there.
>>
>> This bug was discussed in the thread:
>> https://lists.gnu.org/archive/html/qemu-ppc/2021-06/msg00222.html
>>
>> 1- https://git.kernel.org/torvalds/c/cd66cc2ee52
>>
>> Reported-by: <mario@locati.it>
>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>
> One comment,
>
>> ---
>> target/ppc/cpu_init.c | 6 ++++++
>> target/ppc/excp_helper.c | 12 +++++++++++-
>> 2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
>> index 6695985e9b..d8efcb24ed 100644
>> --- a/target/ppc/cpu_init.c
>> +++ b/target/ppc/cpu_init.c
>> @@ -2273,8 +2273,14 @@ static void init_excp_e200(CPUPPCState *env, target_ulong ivpr_mask)
>> env->excp_vectors[POWERPC_EXCP_DTLB] = 0x00000000;
>> env->excp_vectors[POWERPC_EXCP_ITLB] = 0x00000000;
>> env->excp_vectors[POWERPC_EXCP_DEBUG] = 0x00000000;
>> + /*
>> + * These two are the same IVOR as POWERPC_EXCP_VPU and
>> + * POWERPC_EXCP_VPUA. We deal with that when dispatching at
>> + * powerpc_excp().
>> + */
>> env->excp_vectors[POWERPC_EXCP_SPEU] = 0x00000000;
>> env->excp_vectors[POWERPC_EXCP_EFPDI] = 0x00000000;
>> +
>> env->excp_vectors[POWERPC_EXCP_EFPRI] = 0x00000000;
>> env->ivor_mask = 0x0000FFF7UL;
>> env->ivpr_mask = ivpr_mask;
>> diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
>> index 17607adbe4..7bb170f440 100644
>> --- a/target/ppc/excp_helper.c
>> +++ b/target/ppc/excp_helper.c
>> @@ -344,6 +344,16 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int excp_model, int excp)
>> excp = POWERPC_EXCP_PROGRAM;
>> }
>>
>> +#ifdef TARGET_PPC64
>> + /*
>> + * SPEU and VPU share the same IVOR but they exist in different
>> + * processors. SPEU is e500v1/2 only and VPU is e6500 only.
>> + */
>> + if (excp_model == POWERPC_EXCP_BOOKE && excp == POWERPC_EXCP_VPU) {
>> + excp = POWERPC_EXCP_SPEU;
>> + }
>> +#endif
>
> I am not in favor of changing powerpc_excp() but I know you have
> plans for a major clean up :)
Yep, I think is better to fix everything that is broken before the
cleanup so we have more code working and being tested before the
changes.
I would have sent this patch months ago if I knew how to fix it then =)
next prev parent reply other threads:[~2021-12-13 15:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 13:35 [PATCH] target/ppc: Fix e6500 boot Fabiano Rosas
2021-12-13 14:03 ` Cédric Le Goater
2021-12-13 14:59 ` Fabiano Rosas [this message]
2021-12-13 19:51 ` BALATON Zoltan
2021-12-25 18:46 ` mario
2021-12-25 21:53 ` BALATON Zoltan
2021-12-26 17:57 ` Cédric Le Goater
2021-12-27 19:12 ` mario
2021-12-27 20:05 ` Fabiano Rosas
2021-12-27 20:33 ` BALATON Zoltan
2021-12-28 11:32 ` mario
2021-12-27 20:31 ` BALATON Zoltan
2022-01-10 8:04 ` Cédric Le Goater
2022-01-11 9:04 ` mario
2021-12-15 16:52 ` Cédric Le Goater
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=87o85kzh39.fsf@linux.ibm.com \
--to=farosas@linux.ibm.com \
--cc=clg@kaod.org \
--cc=danielhb413@gmail.com \
--cc=mario@locati.it \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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.