From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH v3 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests Date: Wed, 18 Oct 2017 15:21:45 +0200 Message-ID: <20171018132145.GF8900@cbox> References: <1507660725-7986-1-git-send-email-Dave.Martin@arm.com> <1507660725-7986-25-git-send-email-Dave.Martin@arm.com> <20171017135816.GF5886@lvm> <20171017140749.GW19485@e103592.cambridge.arm.com> <2c6d9aa4-f6a8-2c6b-4138-e07d773bf4a2@arm.com> <20171017154708.GY19485@e103592.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Content-Disposition: inline In-Reply-To: <20171017154708.GY19485@e103592.cambridge.arm.com> To: Dave Martin Cc: Marc Zyngier , linux-arch@vger.kernel.org, Okamoto Takayuki , libc-alpha@sourceware.org, Ard Biesheuvel , Szabolcs Nagy , Catalin Marinas , Will Deacon , Richard Sandiford , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org List-Id: linux-arch.vger.kernel.org On Tue, Oct 17, 2017 at 04:47:08PM +0100, Dave Martin wrote: > On Tue, Oct 17, 2017 at 03:29:36PM +0100, Marc Zyngier wrote: > > On 17/10/17 15:07, Dave Martin wrote: > > > On Tue, Oct 17, 2017 at 06:58:16AM -0700, Christoffer Dall wrote: > > >> On Tue, Oct 10, 2017 at 07:38:41PM +0100, Dave Martin wrote: > > >>> KVM guests cannot currently use SVE, because SVE is always > > >>> configured to trap to EL2. > > >>> > > >>> However, a guest that sees SVE reported as present in > > >>> ID_AA64PFR0_EL1 may legitimately expect that SVE works and try to > > >>> use it. Instead of working, the guest will receive an injected > > >>> undef exception, which may cause the guest to oops or go into a > > >>> spin. > > >>> > > >>> To avoid misleading the guest into believing that SVE will work, > > >>> this patch masks out the SVE field from ID_AA64PFR0_EL1 when a > > >>> guest attempts to read this register. No support is explicitly > > >>> added for ID_AA64ZFR0_EL1 either, so that is still emulated as > > >>> reading as zero, which is consistent with SVE not being > > >>> implemented. > > >>> > > >>> This is a temporary measure, and will be removed in a later series > > >>> when full KVM support for SVE is implemented. > > >>> > > >>> Signed-off-by: Dave Martin > > >>> Reviewed-by: Alex Bennée > > >>> Cc: Marc Zyngier > > >>> --- > > >>> arch/arm64/kvm/sys_regs.c | 12 +++++++++++- > > >>> 1 file changed, 11 insertions(+), 1 deletion(-) > > >>> > > >>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > >>> index b1f7552..a0ee9b0 100644 > > >>> --- a/arch/arm64/kvm/sys_regs.c > > >>> +++ b/arch/arm64/kvm/sys_regs.c > > >>> @@ -23,6 +23,7 @@ > > >>> #include > > >>> #include > > >>> #include > > >>> +#include > > >>> #include > > >>> > > >>> #include > > >>> @@ -897,8 +898,17 @@ static u64 read_id_reg(struct sys_reg_desc const *r, bool raz) > > >>> { > > >>> u32 id = sys_reg((u32)r->Op0, (u32)r->Op1, > > >>> (u32)r->CRn, (u32)r->CRm, (u32)r->Op2); > > >>> + u64 val = raz ? 0 : read_sanitised_ftr_reg(id); > > >>> > > >>> - return raz ? 0 : read_sanitised_ftr_reg(id); > > >>> + if (id == SYS_ID_AA64PFR0_EL1) { > > >>> + if (val & (0xfUL << ID_AA64PFR0_SVE_SHIFT)) > > >>> + pr_err_once("kvm [%i]: SVE unsupported for guests, suppressing\n", > > >>> + task_pid_nr(current)); > > >> > > >> nit: does this really qualify as an error print? > > > > > > I have no strong opinion on this: maz suggested I should add this -- > > > his concern was to make it difficult to ignore. > > > > > > This is transitional: the main purpose is to circumvent bug reports from > > > people who find that SVE doesn't work in their guests, in the interim > > > before proper KVM support lands upstream. > > > > > > Marc, do you still agree with this position? > > > > As long as this is transitional, I'm OK with this. > > No argument from me, since it was your request in the first place ;) > > Christoffer? > No (further) argument from me. Thanks, -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com ([74.125.82.65]:49277 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750839AbdJRNVn (ORCPT ); Wed, 18 Oct 2017 09:21:43 -0400 Received: by mail-wm0-f65.google.com with SMTP id b189so9948033wmd.4 for ; Wed, 18 Oct 2017 06:21:42 -0700 (PDT) Date: Wed, 18 Oct 2017 15:21:45 +0200 From: Christoffer Dall Subject: Re: [PATCH v3 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests Message-ID: <20171018132145.GF8900@cbox> References: <1507660725-7986-1-git-send-email-Dave.Martin@arm.com> <1507660725-7986-25-git-send-email-Dave.Martin@arm.com> <20171017135816.GF5886@lvm> <20171017140749.GW19485@e103592.cambridge.arm.com> <2c6d9aa4-f6a8-2c6b-4138-e07d773bf4a2@arm.com> <20171017154708.GY19485@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171017154708.GY19485@e103592.cambridge.arm.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dave Martin Cc: Marc Zyngier , linux-arch@vger.kernel.org, Okamoto Takayuki , libc-alpha@sourceware.org, Ard Biesheuvel , Szabolcs Nagy , Catalin Marinas , Will Deacon , Richard Sandiford , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Message-ID: <20171018132145.BmehPq4DUrFdjv4JAH0Kl7udqSvClsU4f-LII6lIqtI@z> On Tue, Oct 17, 2017 at 04:47:08PM +0100, Dave Martin wrote: > On Tue, Oct 17, 2017 at 03:29:36PM +0100, Marc Zyngier wrote: > > On 17/10/17 15:07, Dave Martin wrote: > > > On Tue, Oct 17, 2017 at 06:58:16AM -0700, Christoffer Dall wrote: > > >> On Tue, Oct 10, 2017 at 07:38:41PM +0100, Dave Martin wrote: > > >>> KVM guests cannot currently use SVE, because SVE is always > > >>> configured to trap to EL2. > > >>> > > >>> However, a guest that sees SVE reported as present in > > >>> ID_AA64PFR0_EL1 may legitimately expect that SVE works and try to > > >>> use it. Instead of working, the guest will receive an injected > > >>> undef exception, which may cause the guest to oops or go into a > > >>> spin. > > >>> > > >>> To avoid misleading the guest into believing that SVE will work, > > >>> this patch masks out the SVE field from ID_AA64PFR0_EL1 when a > > >>> guest attempts to read this register. No support is explicitly > > >>> added for ID_AA64ZFR0_EL1 either, so that is still emulated as > > >>> reading as zero, which is consistent with SVE not being > > >>> implemented. > > >>> > > >>> This is a temporary measure, and will be removed in a later series > > >>> when full KVM support for SVE is implemented. > > >>> > > >>> Signed-off-by: Dave Martin > > >>> Reviewed-by: Alex Bennée > > >>> Cc: Marc Zyngier > > >>> --- > > >>> arch/arm64/kvm/sys_regs.c | 12 +++++++++++- > > >>> 1 file changed, 11 insertions(+), 1 deletion(-) > > >>> > > >>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > >>> index b1f7552..a0ee9b0 100644 > > >>> --- a/arch/arm64/kvm/sys_regs.c > > >>> +++ b/arch/arm64/kvm/sys_regs.c > > >>> @@ -23,6 +23,7 @@ > > >>> #include > > >>> #include > > >>> #include > > >>> +#include > > >>> #include > > >>> > > >>> #include > > >>> @@ -897,8 +898,17 @@ static u64 read_id_reg(struct sys_reg_desc const *r, bool raz) > > >>> { > > >>> u32 id = sys_reg((u32)r->Op0, (u32)r->Op1, > > >>> (u32)r->CRn, (u32)r->CRm, (u32)r->Op2); > > >>> + u64 val = raz ? 0 : read_sanitised_ftr_reg(id); > > >>> > > >>> - return raz ? 0 : read_sanitised_ftr_reg(id); > > >>> + if (id == SYS_ID_AA64PFR0_EL1) { > > >>> + if (val & (0xfUL << ID_AA64PFR0_SVE_SHIFT)) > > >>> + pr_err_once("kvm [%i]: SVE unsupported for guests, suppressing\n", > > >>> + task_pid_nr(current)); > > >> > > >> nit: does this really qualify as an error print? > > > > > > I have no strong opinion on this: maz suggested I should add this -- > > > his concern was to make it difficult to ignore. > > > > > > This is transitional: the main purpose is to circumvent bug reports from > > > people who find that SVE doesn't work in their guests, in the interim > > > before proper KVM support lands upstream. > > > > > > Marc, do you still agree with this position? > > > > As long as this is transitional, I'm OK with this. > > No argument from me, since it was your request in the first place ;) > > Christoffer? > No (further) argument from me. Thanks, -Christoffer