From: Marc Zyngier <marc.zyngier@arm.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Christoffer Dall <christoffer.dall@arm.com>,
Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>, Dave Martin <Dave.Martin@arm.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/5] target/arm: KVM vs ARMISARegisters
Date: Sun, 04 Nov 2018 11:25:00 +0000 [thread overview]
Message-ID: <86zhupdr03.wl-marc.zyngier@arm.com> (raw)
In-Reply-To: <1ee4127a-aa3e-4e19-1dde-af83147f8bc4@linaro.org>
Hi Richard,
On Sun, 04 Nov 2018 09:50:29 +0000,
Richard Henderson <richard.henderson@linaro.org> wrote:
>
> On 11/3/18 12:32 PM, Marc Zyngier wrote:
> > We actively hide the LORegion feature from the guest since
> > cc33c4e20185a391766ed5e78e2acc97e17ba511 (in the 4.17 time frame), so
> > you shouldn't be able to obtain these on a recent host.
>
> I don't think that patch is ideal.
>
> In particular, LOR is a mandatory requirement of ARMv8.1.
> The OS can rightly presume it is present in context.
>
> Better, I think, is to trap the LOR registers, as you are doing,
> and have them act as RAZ/WI. This indicates, via LORID_EL1, that
> there are zero supported LO regions, which is a valid ARMv8.1
> configuration.
I agree this looks like a much better solution. I seem to remember
Mark (now cc'd) battling some half baked implementation that didn't
expose the LOR feature, and yet allowed the various LOR registers to
be freely used, with unknown consequences.
Since we unfortunately need to handle that sorry excuse for a CPU (and
assuming I remember the case correctly), I'd suggest the following
(untested) change:
- We leave the LOR feature visible
- We handle the LOR registers as RAZ/WI
- We still delivering an UNDEF when we're in the aforementioned case.
It would also solve the pathological cases that would result from
mixing 8.0 and 8.1+ CPUs in the same system (yeah, we all foolishly
thought it would never happen...).
Thoughts?
M.
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 22fbbdbece3c..d50f912d3f4a 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -314,10 +314,15 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu,
return read_zero(vcpu, p);
}
-static bool trap_undef(struct kvm_vcpu *vcpu,
- struct sys_reg_params *p,
- const struct sys_reg_desc *r)
+static bool trap_loregion(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
{
+ u64 val = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
+
+ if (val & (0xfUL << ID_AA64MMFR1_LOR_SHIFT))
+ return trap_raz_wi(vcpu, p, r);
+
kvm_inject_undefined(vcpu);
return false;
}
@@ -1040,11 +1045,6 @@ static u64 read_id_reg(struct sys_reg_desc const *r, bool raz)
kvm_debug("SVE unsupported for guests, suppressing\n");
val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
- } else if (id == SYS_ID_AA64MMFR1_EL1) {
- if (val & (0xfUL << ID_AA64MMFR1_LOR_SHIFT))
- kvm_debug("LORegions unsupported for guests, suppressing\n");
-
- val &= ~(0xfUL << ID_AA64MMFR1_LOR_SHIFT);
}
return val;
@@ -1330,11 +1330,11 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_MAIR_EL1), access_vm_reg, reset_unknown, MAIR_EL1 },
{ SYS_DESC(SYS_AMAIR_EL1), access_vm_reg, reset_amair_el1, AMAIR_EL1 },
- { SYS_DESC(SYS_LORSA_EL1), trap_undef },
- { SYS_DESC(SYS_LOREA_EL1), trap_undef },
- { SYS_DESC(SYS_LORN_EL1), trap_undef },
- { SYS_DESC(SYS_LORC_EL1), trap_undef },
- { SYS_DESC(SYS_LORID_EL1), trap_undef },
+ { SYS_DESC(SYS_LORSA_EL1), trap_loregion },
+ { SYS_DESC(SYS_LOREA_EL1), trap_loregion },
+ { SYS_DESC(SYS_LORN_EL1), trap_loregion },
+ { SYS_DESC(SYS_LORC_EL1), trap_loregion },
+ { SYS_DESC(SYS_LORID_EL1), trap_loregion },
{ SYS_DESC(SYS_VBAR_EL1), NULL, reset_val, VBAR_EL1, 0 },
{ SYS_DESC(SYS_DISR_EL1), NULL, reset_val, DISR_EL1, 0 },
--
Jazz is not dead, it just smell funny.
next prev parent reply other threads:[~2018-11-04 11:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-02 14:54 [Qemu-devel] [PATCH v2 0/5] target/arm: KVM vs ARMISARegisters Richard Henderson
2018-11-02 14:54 ` [Qemu-devel] [PATCH v2 1/5] target/arm: Install ARMISARegisters from kvm host Richard Henderson
2018-11-02 14:54 ` [Qemu-devel] [PATCH v2 2/5] target/arm: Fill in ARMISARegisters for kvm64 Richard Henderson
2018-11-02 14:54 ` [Qemu-devel] [PATCH v2 3/5] target/arm: Introduce read_sys_reg32 for kvm32 Richard Henderson
2018-11-02 14:54 ` [Qemu-devel] [PATCH v2 4/5] target/arm: Fill in ARMISARegisters " Richard Henderson
2018-11-02 14:54 ` [Qemu-devel] [PATCH v2 5/5] target/arm: Convert t32ee from feature bit to isar3 test Richard Henderson
2018-11-02 16:36 ` [Qemu-devel] [PATCH v2 0/5] target/arm: KVM vs ARMISARegisters Peter Maydell
2018-11-02 19:35 ` Christoffer Dall
2018-11-03 9:53 ` Richard Henderson
2018-11-03 12:32 ` Marc Zyngier
2018-11-04 9:50 ` Richard Henderson
2018-11-04 11:25 ` Marc Zyngier [this message]
2018-11-05 11:47 ` Mark Rutland
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=86zhupdr03.wl-marc.zyngier@arm.com \
--to=marc.zyngier@arm.com \
--cc=Dave.Martin@arm.com \
--cc=christoffer.dall@arm.com \
--cc=mark.rutland@arm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).