Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp278030pxb; Tue, 19 Oct 2021 02:41:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyVBhPw+7ShSHS0ySVCRuqCr9S3hIjQjcB1wADTGnMKsZX5se1SOEQ01ujubozua5kw70OX X-Received: by 2002:a17:90b:4b4f:: with SMTP id mi15mr5296769pjb.97.1634636497469; Tue, 19 Oct 2021 02:41:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634636497; cv=none; d=google.com; s=arc-20160816; b=qYWeI1xjCVa2YrcwGCtsBS+533/2qrudThlSxRsMX4KUOoRRaKxazDY77UL66a6efc 8MoPFsrvzT9ee1HIY9tQaqhMF1QiwsQ9TDC7nWqBVogwX0LQ3lYX1lnuQZ5ACSIbzhc2 zt8N3QpyLiKJGqEQ5WChANF3XtsAXr4GniE0HSF/VYJ6P7A0sKdk131XIa+k2gl7f2ZR IWSDVZCkd6BYajO6ye8/QIjSyYI25xiJmuAifslYKoRuGpti7W8jKfjDEWd8cbOFkJHO xr3fijF4aNOsXvkbfbjNE8E8zSskBXTDBBjtx31o7F5nu1CDZ+1vEFN7fxQWXizWNj08 05Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+v4Hfkg/w1/B4R5A/ecV7kDZ1+BpxRgtZ9ZYRUTGvYQ=; b=Wof3DR7Al1bHciKKH0HPw0fzFJM8P8qyNL4xq/f/aTcLbifSYT37WWHbOTQ/g4ADpb 5fIo1XVolHjG0X0fU+ki4KSBe0nb+y+aBBTsd2yOvbaq3KtWDNv4Pj1FYDmMQMOaVNuG 1m7x+nUki7ZKi3s3YpgV2lsHyEvwr8NDtdJvJT2voyf6331uVUmhsXPi4vi6NWQ6FjTQ MTLx5jeFWV2Evc1K56s9d0l1xMqqdp3Jg1mrf0+xaAM72lo/MZFFfEGWPH8q5dWeB11x Hus/WpuUue0Rs2JVNRlFZllbFe4eQtQavMIwlKdzDLWJ3jp5T9HtzhUK7NwrS2eGWOAn EBtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SKdRW7si; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a7si22839538pln.79.2021.10.19.02.41.24; Tue, 19 Oct 2021 02:41:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SKdRW7si; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234961AbhJSJmn (ORCPT + 99 others); Tue, 19 Oct 2021 05:42:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234680AbhJSJml (ORCPT ); Tue, 19 Oct 2021 05:42:41 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 017C6C06161C for ; Tue, 19 Oct 2021 02:40:29 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id k7so46397732wrd.13 for ; Tue, 19 Oct 2021 02:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+v4Hfkg/w1/B4R5A/ecV7kDZ1+BpxRgtZ9ZYRUTGvYQ=; b=SKdRW7siAk731anszKLFJ7LCVf1ZukxuHCQa9UfvTaS+LMfaeSqnc+PdFEyz2b9Vql R9n2h4pfsBE+hTtl9Ghcf73/JuT7EvSbvrayRN4ynnOPhQo2YSbaa2uPZt5r4puv5gfK GaTMyTPjRRQgvhLvowqAFIDI+9cKrp/IeO9ZAC8t6pdqf4w8t/Q1YC4NIoHvacb0FPms Cgm3gUBIOrm4FhPkuzjC6bGgzVMTNnDNWmpEOZz92J1kYF54KTktv+6+qRpIPIOleMfH 7rW14/k/BiowMiLxGBg2YIKmhi2tV85quWfj9WotO4rPM5TGN+7tWvTBQUosIYMhYK9X v8wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+v4Hfkg/w1/B4R5A/ecV7kDZ1+BpxRgtZ9ZYRUTGvYQ=; b=Oq5ehedJSFXgqqV71DBzuQ/rkmsayz3pPTtlqlrOkZjJPzpRRqSwC/+XzCDBYlORxw 4HGzVvpiGCGVg4No8QYVoYoSY/4raMpNyLk5h0gZrh7qocWunhqpr9815bvqX7z5LU+p U8A1X04X+Oxybkq3kkgh4xNeqbbIuFT9+viCMkWQRuk1uam4w/QQaT6wYg24Xgu9m6m2 P9BwEodJE1Cw8z7FF8zdluTPbWyujRYDoTrjK2mcPBlFurVAyvBXz0DIpeOTsjyhS2tL ckD6YuYhAqgFY5Rk4r+qWMuucBXOZjM9cO8ZYMhSEC87j4FRVkXFjQBdnuvtp9FYElLc dfHQ== X-Gm-Message-State: AOAM531EzRiGDTJt52QQgQ/e+9bFN9rkPCINNbUvw+cU3sDm8sn9fSe2 XxZNA0I5z+oRZyt2MsVzw5HsbQ== X-Received: by 2002:adf:ec46:: with SMTP id w6mr29994052wrn.240.1634636427307; Tue, 19 Oct 2021 02:40:27 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:59ca:401f:83a8:de6d]) by smtp.gmail.com with ESMTPSA id g33sm1594777wmp.45.2021.10.19.02.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 02:40:26 -0700 (PDT) Date: Tue, 19 Oct 2021 10:40:24 +0100 From: Quentin Perret To: Marc Zyngier Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Fuad Tabba , David Brazdil , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 16/16] KVM: arm64: pkvm: Unshare guest structs during teardown Message-ID: References: <20211013155831.943476-1-qperret@google.com> <20211013155831.943476-17-qperret@google.com> <87h7dhupfa.wl-maz@kernel.org> <3ec8ab06f9950a13818109051835fdb9@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ec8ab06f9950a13818109051835fdb9@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 18 Oct 2021 at 18:12:22 (+0100), Marc Zyngier wrote: > On 2021-10-18 15:03, Quentin Perret wrote: > > On Monday 18 Oct 2021 at 11:32:13 (+0100), Quentin Perret wrote: > > > Another option is to take a refcount on 'current' from > > > kvm_arch_vcpu_run_map_fp() before sharing thread-specific structs with > > > the hyp and release the refcount of the previous task after unsharing. > > > But that means we'll have to also drop the refcount when the vcpu > > > gets destroyed, as well as explicitly unshare at that point. Shouldn't > > > be too bad I think. Thoughts? > > > > Something like the below seems to work OK on my setup, including > > SIGKILL'ing the guest and such. How much do you hate it? > > It is annoyingly elegant! Small nitpick below. > > > > > diff --git a/arch/arm64/include/asm/kvm_host.h > > b/arch/arm64/include/asm/kvm_host.h > > index f8be56d5342b..50598d704c71 100644 > > --- a/arch/arm64/include/asm/kvm_host.h > > +++ b/arch/arm64/include/asm/kvm_host.h > > @@ -322,6 +322,7 @@ struct kvm_vcpu_arch { > > > > struct thread_info *host_thread_info; /* hyp VA */ > > struct user_fpsimd_state *host_fpsimd_state; /* hyp VA */ > > + struct task_struct *parent_task; > > > > struct { > > /* {Break,watch}point registers */ > > @@ -738,6 +739,7 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu); > > void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu); > > void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu); > > void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu); > > +void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu); > > > > static inline bool kvm_pmu_counter_deferred(struct perf_event_attr > > *attr) > > { > > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c > > index 2fe1128d9f3d..27afeebbe1cb 100644 > > --- a/arch/arm64/kvm/fpsimd.c > > +++ b/arch/arm64/kvm/fpsimd.c > > @@ -15,6 +15,22 @@ > > #include > > #include > > > > +void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu) > > +{ > > + struct task_struct *p = vcpu->arch.parent_task; > > + struct user_fpsimd_state *fpsimd; > > + struct thread_info *ti; > > + > > + if (!static_branch_likely(&kvm_protected_mode_initialized) || !p) > > Shouldn't this be a check on is_protected_kvm_enabled() instead? > The two should be equivalent outside of the initialisation code... Yup, it'd be nice to do checks on kvm_protected_mode_initialized only when they're strictly necessary, and that's not the case here. I'll fold that change in v2. Cheers Quentin