From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org,
Adam Lackorzynski <adam.lackorzynski@kernkonzept.com>,
patches@linaro.org
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH for-v3.1 1/3] Revert "target/arm: Implement HCR.VI and VF"
Date: Mon, 12 Nov 2018 11:54:42 +0000 [thread overview]
Message-ID: <87in12ecjh.fsf@linaro.org> (raw)
In-Reply-To: <20181109134731.11605-2-peter.maydell@linaro.org>
Peter Maydell <peter.maydell@linaro.org> writes:
> This reverts commit 8a0fc3a29fc2315325400c738f807d0d4ae0ab7f.
>
> The implementation of HCR.VI and VF in that commit is not
> correct -- they do not track the overall "is there a pending
> VIRQ or VFIQ" status, but whether there is a pending interrupt
> due to "this mechanism", ie the hypervisor having set the VI/VF
> bits. The overall pending state for VIRQ and VFIQ is effectively
> the logical OR of the inbound lines from the GIC with the
> VI and VF bits. Commit 8a0fc3a29fc231 would result in pending
> VIRQ/VFIQ possibly being lost when the hypervisor wrote to HCR.
>
> As a preliminary to implementing the HCR.VI/VF feature properly,
> revert the broken one entirely.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> target/arm/helper.c | 47 ++++-----------------------------------------
> 1 file changed, 4 insertions(+), 43 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 851ea9aa977..f3878f505b7 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -3931,7 +3931,6 @@ static const ARMCPRegInfo el3_no_el2_v8_cp_reginfo[] = {
> static void hcr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value)
> {
> ARMCPU *cpu = arm_env_get_cpu(env);
> - CPUState *cs = ENV_GET_CPU(env);
> uint64_t valid_mask = HCR_MASK;
>
> if (arm_feature(env, ARM_FEATURE_EL3)) {
> @@ -3950,28 +3949,6 @@ static void hcr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value)
> /* Clear RES0 bits. */
> value &= valid_mask;
>
> - /*
> - * VI and VF are kept in cs->interrupt_request. Modifying that
> - * requires that we have the iothread lock, which is done by
> - * marking the reginfo structs as ARM_CP_IO.
> - * Note that if a write to HCR pends a VIRQ or VFIQ it is never
> - * possible for it to be taken immediately, because VIRQ and
> - * VFIQ are masked unless running at EL0 or EL1, and HCR
> - * can only be written at EL2.
> - */
> - g_assert(qemu_mutex_iothread_locked());
> - if (value & HCR_VI) {
> - cs->interrupt_request |= CPU_INTERRUPT_VIRQ;
> - } else {
> - cs->interrupt_request &= ~CPU_INTERRUPT_VIRQ;
> - }
> - if (value & HCR_VF) {
> - cs->interrupt_request |= CPU_INTERRUPT_VFIQ;
> - } else {
> - cs->interrupt_request &= ~CPU_INTERRUPT_VFIQ;
> - }
> - value &= ~(HCR_VI | HCR_VF);
> -
> /* These bits change the MMU setup:
> * HCR_VM enables stage 2 translation
> * HCR_PTW forbids certain page-table setups
> @@ -3999,32 +3976,16 @@ static void hcr_writelow(CPUARMState *env, const ARMCPRegInfo *ri,
> hcr_write(env, NULL, value);
> }
>
> -static uint64_t hcr_read(CPUARMState *env, const ARMCPRegInfo *ri)
> -{
> - /* The VI and VF bits live in cs->interrupt_request */
> - uint64_t ret = env->cp15.hcr_el2 & ~(HCR_VI | HCR_VF);
> - CPUState *cs = ENV_GET_CPU(env);
> -
> - if (cs->interrupt_request & CPU_INTERRUPT_VIRQ) {
> - ret |= HCR_VI;
> - }
> - if (cs->interrupt_request & CPU_INTERRUPT_VFIQ) {
> - ret |= HCR_VF;
> - }
> - return ret;
> -}
> -
> static const ARMCPRegInfo el2_cp_reginfo[] = {
> { .name = "HCR_EL2", .state = ARM_CP_STATE_AA64,
> - .type = ARM_CP_IO,
> .opc0 = 3, .opc1 = 4, .crn = 1, .crm = 1, .opc2 = 0,
> .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.hcr_el2),
> - .writefn = hcr_write, .readfn = hcr_read },
> + .writefn = hcr_write },
> { .name = "HCR", .state = ARM_CP_STATE_AA32,
> - .type = ARM_CP_ALIAS | ARM_CP_IO,
> + .type = ARM_CP_ALIAS,
> .cp = 15, .opc1 = 4, .crn = 1, .crm = 1, .opc2 = 0,
> .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.hcr_el2),
> - .writefn = hcr_writelow, .readfn = hcr_read },
> + .writefn = hcr_writelow },
> { .name = "ELR_EL2", .state = ARM_CP_STATE_AA64,
> .type = ARM_CP_ALIAS,
> .opc0 = 3, .opc1 = 4, .crn = 4, .crm = 0, .opc2 = 1,
> @@ -4261,7 +4222,7 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
>
> static const ARMCPRegInfo el2_v8_cp_reginfo[] = {
> { .name = "HCR2", .state = ARM_CP_STATE_AA32,
> - .type = ARM_CP_ALIAS | ARM_CP_IO,
> + .type = ARM_CP_ALIAS,
> .cp = 15, .opc1 = 4, .crn = 1, .crm = 1, .opc2 = 4,
> .access = PL2_RW,
> .fieldoffset = offsetofhigh32(CPUARMState, cp15.hcr_el2),
--
Alex Bennée
next prev parent reply other threads:[~2018-11-12 11:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 13:47 [Qemu-devel] [PATCH for-v3.1 0/3] Fix handling of HCR.VI and VF Peter Maydell
2018-11-09 13:47 ` [Qemu-devel] [PATCH for-v3.1 1/3] Revert "target/arm: Implement HCR.VI and VF" Peter Maydell
2018-11-12 0:15 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
2018-11-12 11:54 ` Alex Bennée [this message]
2018-11-09 13:47 ` [Qemu-devel] [PATCH for-v3.1 2/3] target/arm: Track the state of our irq lines from the GIC explicitly Peter Maydell
2018-11-11 23:45 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
2018-11-12 11:58 ` Alex Bennée
2018-11-09 13:47 ` [Qemu-devel] [PATCH for-v3.1 3/3] target/arm: Correctly implement handling of HCR_EL2.{VI, VF} Peter Maydell
2018-11-12 0:14 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
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=87in12ecjh.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=adam.lackorzynski@kernkonzept.com \
--cc=patches@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).