[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191223115651.GA42593@e119886-lin.cambridge.arm.com>
Date: Mon, 23 Dec 2019 11:56:52 +0000
From: Andrew Murray <andrew.murray@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: Marc Zyngier <marc.zyngier@....com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Sudeep Holla <sudeep.holla@....com>,
kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 11/18] KVM: arm64: don't trap Statistical Profiling
controls to EL2
On Sun, Dec 22, 2019 at 10:42:05AM +0000, Marc Zyngier wrote:
> On Fri, 20 Dec 2019 14:30:18 +0000,
> Andrew Murray <andrew.murray@....com> wrote:
> >
> > As we now save/restore the profiler state there is no need to trap
> > accesses to the statistical profiling controls. Let's unset the
> > _TPMS bit.
> >
> > Signed-off-by: Andrew Murray <andrew.murray@....com>
> > ---
> > arch/arm64/kvm/debug.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> > index 43487f035385..07ca783e7d9e 100644
> > --- a/arch/arm64/kvm/debug.c
> > +++ b/arch/arm64/kvm/debug.c
> > @@ -88,7 +88,6 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
> > * - Performance monitors (MDCR_EL2_TPM/MDCR_EL2_TPMCR)
> > * - Debug ROM Address (MDCR_EL2_TDRA)
> > * - OS related registers (MDCR_EL2_TDOSA)
> > - * - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
> > *
> > * Additionally, KVM only traps guest accesses to the debug registers if
> > * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
> > @@ -111,7 +110,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
> > */
> > vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
> > vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
> > - MDCR_EL2_TPMS |
>
> No. This is an *optional* feature (the guest could not be presented
> with the SPE feature, or the the support simply not be compiled in).
>
> If the guest is not allowed to see the feature, for whichever reason,
> the traps *must* be enabled and handled.
I'll update this (and similar) to trap such registers when we don't support
SPE in the guest.
My original concern in the cover letter was in how to prevent the guest
from attempting to use these registers in the first place - I think the
solution I was looking for is to trap-and-emulate ID_AA64DFR0_EL1 such that
the PMSVer bits indicate that SPE is not emulated.
Thanks,
Andrew Murray
>
> M.
>
> --
> Jazz is not dead, it just smells funny.
Powered by blists - more mailing lists