Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
On 11/23/19 11:56 AM, Marc Zyngier wrote: > HCR_EL2.TID3 mandates that access from EL1 to a long list of id > registers traps to EL2, and QEMU has so far ignored this requirement. > > This breaks (among other things) KVM guests that have PtrAuth enabled, > while the hypervisor doesn't want to expose the feature to its guest. > To achieve this, KVM traps the ID registers (ID_AA64ISAR1_EL1 in this > case), and masks out the unsupported feature. > > QEMU not honoring the trap request means that the guest observes > that the feature is present in the HW, starts using it, and dies > a horrible death when KVM injects an UNDEF, because the feature > *really* isn't supported. > > Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set. > > Reported-by: Will Deacon > Signed-off-by: Marc Zyngier > --- > There is a number of other trap bits missing (TID[0-2], for example), > but this at least gets a mainline Linux going with cpu=max. BTW, Peter, this appears to have been the bug that was causing me so many problems on my VHE branch. Probably *exactly* this bug wrt ptrauth, since that would also be included with -cpu max. I am now able to boot a kvm guest kernel to the point of the no rootfs panic, which I wasn't before. I can only think that I mis-identified the true cause in Lyon. Anyway, thanks Marc! r~ ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
On Tue, 26 Nov 2019 at 10:12, Richard Henderson
wrote:
>
> On 11/23/19 11:56 AM, Marc Zyngier wrote:
> > +static CPAccessResult access_aa64idreg(CPUARMState *env, const
> > ARMCPRegInfo *ri,
> > + bool isread)
> > +{
> > +if ((arm_current_el(env) < 2) && (arm_hcr_el2_eff(env) & HCR_TID3)) {
> > +return CP_ACCESS_TRAP_EL2;
> > +}
> > +
> > +return CP_ACCESS_OK;
> > +}
> > +
>
> The only thing I would suggest is to call this access_aa64_tid3, because
> tid{0,1,2} also need to be handled in a similar way, and we'll need little
> helper functions for those too.
Good idea, I will make that change also.
-- PMM
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
On Mon, 25 Nov 2019 at 17:49, Marc Zyngier wrote: > I also had a look at TID0, but couldn't find any of the Jazelle > stuff in QEMU... We implement only "minimal Jazelle", ie the minimal set of registers needed to be architecturally compliant for an implementation without Jazelle. thanks -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
On 11/23/19 11:56 AM, Marc Zyngier wrote:
> +static CPAccessResult access_aa64idreg(CPUARMState *env, const ARMCPRegInfo
> *ri,
> + bool isread)
> +{
> +if ((arm_current_el(env) < 2) && (arm_hcr_el2_eff(env) & HCR_TID3)) {
> +return CP_ACCESS_TRAP_EL2;
> +}
> +
> +return CP_ACCESS_OK;
> +}
> +
The only thing I would suggest is to call this access_aa64_tid3, because
tid{0,1,2} also need to be handled in a similar way, and we'll need little
helper functions for those too.
r~
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
RE: [RFC PATCH v8 3/8] ptp: Reorganize ptp_kvm modules to make it arch-independent.
Hi Marc,
> -Original Message-
> From: Marc Zyngier
> Sent: Monday, November 25, 2019 11:48 PM
> To: Jianyong Wu (Arm Technology China)
> Cc: net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linaro.org;
> t...@linutronix.de; pbonz...@redhat.com; sean.j.christopher...@intel.com;
> richardcoch...@gmail.com; Mark Rutland ;
> w...@kernel.org; Suzuki Poulose ; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; k...@vger.kernel.org; Steve Capper
> ; Kaly Xin (Arm Technology China)
> ; Justin He (Arm Technology China)
> ; nd
> Subject: Re: [RFC PATCH v8 3/8] ptp: Reorganize ptp_kvm modules to make it
> arch-independent.
>
> On 2019-11-25 10:45, Jianyong Wu wrote:
> > Currently, ptp_kvm modules implementation is only for x86 which
> > includs large part of arch-specific code. This patch move all of
> > those code into new arch related file in the same directory.
> >
> > Signed-off-by: Jianyong Wu
> > ---
> > drivers/ptp/Makefile| 1 +
> > drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} | 77 +-
> > drivers/ptp/ptp_kvm_x86.c | 87
> > +
> > include/asm-generic/ptp_kvm.h | 12 +++
> > 4 files changed, 118 insertions(+), 59 deletions(-) rename
> > drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} (63%) create mode
> 100644
> > drivers/ptp/ptp_kvm_x86.c create mode 100644
> > include/asm-generic/ptp_kvm.h
>
> [...]
>
> > diff --git a/include/asm-generic/ptp_kvm.h
> > b/include/asm-generic/ptp_kvm.h new file mode 100644 index
> > ..e5dd386f6664
> > --- /dev/null
> > +++ b/include/asm-generic/ptp_kvm.h
> > @@ -0,0 +1,12 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Virtual PTP 1588 clock for use with KVM guests
> > + *
> > + * Copyright (C) 2019 ARM Ltd.
>
> I think you should live the original copyright assignment here.
> This really isn't anything new.
>
Ok,
> > + * All Rights Reserved
> > + */
> > +
> > +int kvm_arch_ptp_init(void);
> > +int kvm_arch_ptp_get_clock(struct timespec64 *ts); int
> > +kvm_arch_ptp_get_crosststamp(unsigned long *cycle,
> > + struct timespec64 *tspec, void *cs);
>
> Why is this include file in asm-generic? This isn't a kernel-wide API.
>
> I think it should be sitting in drivers/ptp, as it is only shared between the
> generic and arch-specific stuff.
Ok, all these APIs used under driver/ptp, so it's better to move that header
file into it.
Thanks
Jianyong
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
