From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Christophe Lyon" <christophe.lyon@linaro.org>
Subject: Re: [PATCH for-4.1] target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026
Date: Thu, 11 Jul 2019 14:43:18 +0200 [thread overview]
Message-ID: <21ffce4e-72cf-2c5f-71b1-cb53367dccda@linaro.org> (raw)
In-Reply-To: <20190711121231.3601-1-peter.maydell@linaro.org>
On 7/11/19 2:12 PM, Peter Maydell wrote:
> The ARMv5 architecture didn't specify detailed per-feature ID
> registers. Now that we're using the MVFR0 register fields to
> gate the existence of VFP instructions, we need to set up
> the correct values in the cpu->isar structure so that we still
> provide an FPU to the guest.
>
> This fixes a regression in the arm926 and arm1026 CPUs, which
> are the only ones that both have VFP and are ARMv5 or earlier.
> This regression was introduced by the VFP refactoring, and more
> specifically by commits 1120827fa182f0e76 and 266bd25c485597c,
> which accidentally disabled VFP short-vector support and
> double-precision support on these CPUs.
>
> Reported-by: Christophe Lyon <christophe.lyon@linaro.org>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> Fixes: 1120827fa182f0e
> Fixes: 266bd25c485597c
> Fixes: https://bugs.launchpad.net/qemu/+bug/1836192
> ---
> I've followed the existing approach we used for ISAR1 here
> of just filling in the fields we care about, rather than trying
> to set the entire register value.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> @@ -1713,6 +1719,12 @@ static void arm1026_initfn(Object *obj)
> };
> define_one_arm_cp_reg(cpu, &ifar);
> }
> + /*
> + * Similarly, we need to set MVFR0 fields to enable double precision
> + * and short vector support even though ARMv5 doesn't have this register.
> + */
> + cpu->isar.mvfr0 = FIELD_DP32(cpu->isar.mvfr0, MVFR0, FPSHVEC, 1);
> + cpu->isar.mvfr0 = FIELD_DP32(cpu->isar.mvfr0, MVFR0, FPDP, 1);
> }
I would have placed this immediately after the Jazelle isar setup, so that the
"Similarly" comment had the proper referent. But, no biggie.
r~
WARNING: multiple messages have this Message-ID (diff)
From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: "Christophe Lyon" <christophe.lyon@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [PATCH for-4.1] target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026
Date: Thu, 11 Jul 2019 14:43:18 +0200 [thread overview]
Message-ID: <21ffce4e-72cf-2c5f-71b1-cb53367dccda@linaro.org> (raw)
In-Reply-To: <20190711121231.3601-1-peter.maydell@linaro.org>
On 7/11/19 2:12 PM, Peter Maydell wrote:
> The ARMv5 architecture didn't specify detailed per-feature ID
> registers. Now that we're using the MVFR0 register fields to
> gate the existence of VFP instructions, we need to set up
> the correct values in the cpu->isar structure so that we still
> provide an FPU to the guest.
>
> This fixes a regression in the arm926 and arm1026 CPUs, which
> are the only ones that both have VFP and are ARMv5 or earlier.
> This regression was introduced by the VFP refactoring, and more
> specifically by commits 1120827fa182f0e76 and 266bd25c485597c,
> which accidentally disabled VFP short-vector support and
> double-precision support on these CPUs.
>
> Reported-by: Christophe Lyon <christophe.lyon@linaro.org>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> Fixes: 1120827fa182f0e
> Fixes: 266bd25c485597c
> Fixes: https://bugs.launchpad.net/qemu/+bug/1836192
> ---
> I've followed the existing approach we used for ISAR1 here
> of just filling in the fields we care about, rather than trying
> to set the entire register value.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> @@ -1713,6 +1719,12 @@ static void arm1026_initfn(Object *obj)
> };
> define_one_arm_cp_reg(cpu, &ifar);
> }
> + /*
> + * Similarly, we need to set MVFR0 fields to enable double precision
> + * and short vector support even though ARMv5 doesn't have this register.
> + */
> + cpu->isar.mvfr0 = FIELD_DP32(cpu->isar.mvfr0, MVFR0, FPSHVEC, 1);
> + cpu->isar.mvfr0 = FIELD_DP32(cpu->isar.mvfr0, MVFR0, FPDP, 1);
> }
I would have placed this immediately after the Jazelle isar setup, so that the
"Similarly" comment had the proper referent. But, no biggie.
r~
next prev parent reply other threads:[~2019-07-11 12:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 12:12 [PATCH for-4.1] target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026 Peter Maydell
2019-07-11 12:12 ` [Qemu-devel] " Peter Maydell
2019-07-11 12:43 ` Richard Henderson [this message]
2019-07-11 12:43 ` Richard Henderson
2019-07-11 12:46 ` Peter Maydell
2019-07-11 12:46 ` [Qemu-devel] " Peter Maydell
2019-07-11 13:01 ` Alex Bennée
2019-07-11 13:01 ` [Qemu-devel] " Alex Bennée
2019-07-11 13:02 ` Peter Maydell
2019-07-11 13:02 ` [Qemu-devel] " Peter Maydell
2019-07-11 16:25 ` no-reply
2019-07-11 16:25 ` no-reply
2019-07-11 16:27 ` no-reply
2019-07-11 16:27 ` no-reply
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=21ffce4e-72cf-2c5f-71b1-cb53367dccda@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=christophe.lyon@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@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.