From: James Morse <james.morse@arm.com> To: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier <maz@kernel.org> Subject: [PATCH 0/3] KVM: arm64: aarch32 ACTLR accesses Date: Tue, 26 May 2020 16:18:31 +0000 [thread overview] Message-ID: <20200526161834.29165-1-james.morse@arm.com> (raw) Hello! Patch 1 fixes an issue where the 32bit and 64bit indexes into copro[] and sys_regs[] are muddled. Patch 3 adds support for aarch32 accessing the top 32bits of ACTLR_EL1 via ACTLR2. Support for this register is advertised in ID_MMFR4.AC2, which doesn't get removed by cpufeature. The register is mandatory from v8.2, but imp-def before then. Patch 2 stops the sys_regs[] value we use for emulation being save/restored. This simplifies patch 3 as the aarch32 helper can rely on the in-memory copy. I think Patch 1 is stable material, I'm not sure about 2&3. Bonus cans of worms!: 1. How does this copro[] thing work with a big-endian host? The cp15_regs emulation look fine as nothing uses vcpu_cp15() to read the register, but wouldn't prepare_fault32() read the wrong end of the register when using vcpu_cp15()? 2. How does the 32bit fault injection code work with VHE? vcpu_cp15() modifies the in-memory copy, surely a vcpu_put() will clobber everything it did, or fail to restore it when entering the guest. Thanks, James Morse (3): KVM: arm64: Stop writing aarch32's CSSELR into ACTLR KVM: arm64: Stop save/restoring ACTLR_EL1 KVM: arm64: Add emulation for 32bit guests accessing ACTLR2 arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/kvm/hyp/sysreg-sr.c | 2 -- arch/arm64/kvm/sys_regs.c | 8 +++----- arch/arm64/kvm/sys_regs_generic_v8.c | 16 +++++++++++++++- 4 files changed, 19 insertions(+), 8 deletions(-) -- 2.20.1 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com> To: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>, Julien Thierry <julien.thierry.kdev@gmail.com>, Suzuki K Poulose <suzuki.poulose@arm.com> Subject: [PATCH 0/3] KVM: arm64: aarch32 ACTLR accesses Date: Tue, 26 May 2020 16:18:31 +0000 [thread overview] Message-ID: <20200526161834.29165-1-james.morse@arm.com> (raw) Hello! Patch 1 fixes an issue where the 32bit and 64bit indexes into copro[] and sys_regs[] are muddled. Patch 3 adds support for aarch32 accessing the top 32bits of ACTLR_EL1 via ACTLR2. Support for this register is advertised in ID_MMFR4.AC2, which doesn't get removed by cpufeature. The register is mandatory from v8.2, but imp-def before then. Patch 2 stops the sys_regs[] value we use for emulation being save/restored. This simplifies patch 3 as the aarch32 helper can rely on the in-memory copy. I think Patch 1 is stable material, I'm not sure about 2&3. Bonus cans of worms!: 1. How does this copro[] thing work with a big-endian host? The cp15_regs emulation look fine as nothing uses vcpu_cp15() to read the register, but wouldn't prepare_fault32() read the wrong end of the register when using vcpu_cp15()? 2. How does the 32bit fault injection code work with VHE? vcpu_cp15() modifies the in-memory copy, surely a vcpu_put() will clobber everything it did, or fail to restore it when entering the guest. Thanks, James Morse (3): KVM: arm64: Stop writing aarch32's CSSELR into ACTLR KVM: arm64: Stop save/restoring ACTLR_EL1 KVM: arm64: Add emulation for 32bit guests accessing ACTLR2 arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/kvm/hyp/sysreg-sr.c | 2 -- arch/arm64/kvm/sys_regs.c | 8 +++----- arch/arm64/kvm/sys_regs_generic_v8.c | 16 +++++++++++++++- 4 files changed, 19 insertions(+), 8 deletions(-) -- 2.20.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-05-26 16:18 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-26 16:18 James Morse [this message] 2020-05-26 16:18 ` [PATCH 0/3] KVM: arm64: aarch32 ACTLR accesses James Morse 2020-05-26 16:18 ` [PATCH 1/3] KVM: arm64: Stop writing aarch32's CSSELR into ACTLR James Morse 2020-05-26 16:18 ` James Morse 2020-05-26 16:18 ` James Morse 2020-05-27 16:57 ` Sasha Levin 2020-05-27 16:57 ` Sasha Levin 2020-05-27 16:57 ` Sasha Levin 2020-05-28 8:57 ` Marc Zyngier 2020-05-28 8:57 ` Marc Zyngier 2020-05-28 8:57 ` Marc Zyngier 2020-05-28 11:59 ` James Morse 2020-05-28 11:59 ` James Morse 2020-05-28 11:59 ` James Morse 2020-05-28 12:10 ` Marc Zyngier 2020-05-28 12:10 ` Marc Zyngier 2020-05-28 12:10 ` Marc Zyngier 2020-05-26 16:18 ` [PATCH 2/3] KVM: arm64: Stop save/restoring ACTLR_EL1 James Morse 2020-05-26 16:18 ` James Morse 2020-05-28 12:36 ` Marc Zyngier 2020-05-28 12:36 ` Marc Zyngier 2020-05-28 12:38 ` Marc Zyngier 2020-05-28 12:38 ` Marc Zyngier 2020-05-28 12:55 ` James Morse 2020-05-28 12:55 ` James Morse 2020-05-26 16:18 ` [PATCH 3/3] KVM: arm64: Add emulation for 32bit guests accessing ACTLR2 James Morse 2020-05-26 16:18 ` James Morse 2020-05-28 12:51 ` Marc Zyngier 2020-05-28 12:51 ` Marc Zyngier 2020-05-31 13:37 ` [PATCH 0/3] KVM: arm64: aarch32 ACTLR accesses Marc Zyngier 2020-05-31 13:37 ` Marc Zyngier
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=20200526161834.29165-1-james.morse@arm.com \ --to=james.morse@arm.com \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=maz@kernel.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: linkBe 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.