From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AD07C433FE for ; Fri, 7 Jan 2022 06:07:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231627AbiAGGHM (ORCPT ); Fri, 7 Jan 2022 01:07:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230466AbiAGGHK (ORCPT ); Fri, 7 Jan 2022 01:07:10 -0500 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34EAFC061201 for ; Thu, 6 Jan 2022 22:07:10 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id m13so4363584pji.3 for ; Thu, 06 Jan 2022 22:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2q58XOryfIlXBk+Ga94YK5KAiqVRv5tmtrlFtSkfC0E=; b=ochKJUmv9jcYYqjl8Ri0yXzDhwacQ2/M9JFDOvS2FBy8XLGNBzhfSvKLa9ii/FgSHR lKXPiHPPHOi42VPVoABzyceIiJ8F+Kbs3IS0k75hH2A5mdF2XigOH5lmdKWrpcwtxdbr ezxvlB8NX6lqdXgr7vLxp+V4EZIGdh1LCkEFmJztS6KTyCd2fXWSEdqhhi3oBwVmS13w /pYkJOH9knWKKZPd/LGxDD94eatNe6H5EBW+iGlQr71hEgAmZVB6ZiK24VPUj2ooMIaj 42ZKBZFHvnOHD474TolWmS+OmhGNji04Be9HsERGLppfG0rRjME6jGJDuXtYXGuWgZIu K72Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2q58XOryfIlXBk+Ga94YK5KAiqVRv5tmtrlFtSkfC0E=; b=fqJn4kmzIN6WJ3lj4gZXRAuYmo7nEWSpTHF8yqLNblkWLuPya61F+9SrAMebwJqlHe MbFBo+9+5f+l3mCzTiCnhGzn9F35yzx5Tv/5GhmslsUHprWSaGgzfT52uBT26+oVRKrm hYyo6G1ZqBYEl+Ibtlt7PV0g/84IDcl0WRkx7MoRenXK5fZrmtvAIMNkQCa4545ygFYP 1PSCY0yfHakkQniDAXsaq3qAzhVaLmIy31DDhA/rxvgMFv7e8HqX1H94zl8LZGHoJi21 TP7mzzgVDj4HMBqZlzfmMcPNHfMc8xXPZB/KIzIZgvWCaiH9kEAlvm/bAkiv9ZS3f3nq gRVw== X-Gm-Message-State: AOAM533fSb4yBlYGLB59m9OzQCJy0Iz1sTtg3oDzFbk3Eg0UdmfJDzw8 4hcXHCi/ktTWgxBFOKiyAS6U5DReJZH6+JepbiRkrw== X-Google-Smtp-Source: ABdhPJzi8RhMHj39b+4Rn0KshD189vXaFIX2vj8EwamLndmdEQUpG8o9KUsh8L5L/q0EpOVykikO8FcKUk+BveZguG8= X-Received: by 2002:a17:902:c652:b0:148:f1a5:b7bf with SMTP id s18-20020a170902c65200b00148f1a5b7bfmr62134703pls.122.1641535629407; Thu, 06 Jan 2022 22:07:09 -0800 (PST) MIME-Version: 1.0 References: <20220104194918.373612-1-rananta@google.com> <20220104194918.373612-2-rananta@google.com> In-Reply-To: <20220104194918.373612-2-rananta@google.com> From: Reiji Watanabe Date: Thu, 6 Jan 2022 22:06:53 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Raghavendra Rao Ananta Cc: Marc Zyngier , Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Linux ARM , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Raghu, On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta wrote: > > Capture the start of the KVM VM, which is basically the > start of any vCPU run. This state of the VM is helpful > in the upcoming patches to prevent user-space from > configuring certain VM features after the VM has started > running. > > Signed-off-by: Raghavendra Rao Ananta > --- > include/linux/kvm_host.h | 3 +++ > virt/kvm/kvm_main.c | 9 +++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index c310648cc8f1..d0bd8f7a026c 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -623,6 +623,7 @@ struct kvm { > struct notifier_block pm_notifier; > #endif > char stats_id[KVM_STATS_NAME_SIZE]; > + bool vm_started; Since KVM_RUN on any vCPUs doesn't necessarily mean that the VM started yet, the name might be a bit misleading IMHO. I would think 'has_run_once' or 'ran_once' might be more clear (?). > }; > > #define kvm_err(fmt, ...) \ > @@ -1666,6 +1667,8 @@ static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu) > } > } > > +#define kvm_vm_has_started(kvm) (kvm->vm_started) > + > extern bool kvm_rebooting; > > extern unsigned int halt_poll_ns; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 72c4e6b39389..962b91ac2064 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3686,6 +3686,7 @@ static long kvm_vcpu_ioctl(struct file *filp, > int r; > struct kvm_fpu *fpu = NULL; > struct kvm_sregs *kvm_sregs = NULL; > + struct kvm *kvm = vcpu->kvm; > > if (vcpu->kvm->mm != current->mm || vcpu->kvm->vm_dead) > return -EIO; > @@ -3723,6 +3724,14 @@ static long kvm_vcpu_ioctl(struct file *filp, > if (oldpid) > synchronize_rcu(); > put_pid(oldpid); > + > + /* > + * Since we land here even on the first vCPU run, > + * we can mark that the VM has started running. > + */ It might be nicer to add a comment why the code below gets kvm->lock. Anyway, the patch generally looks good to me, and thank you for making this change (it works for my purpose as well). Reviewed-by: Reiji Watanabe Thanks, Reiji > + mutex_lock(&kvm->lock); > + kvm->vm_started = true; > + mutex_unlock(&kvm->lock); > } > r = kvm_arch_vcpu_ioctl_run(vcpu); > trace_kvm_userspace_exit(vcpu->run->exit_reason, r); > -- > 2.34.1.448.ga2b2bfdf31-goog > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4BFAC433F5 for ; Fri, 7 Jan 2022 06:07:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 307F349FE6; Fri, 7 Jan 2022 01:07:14 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4JDePualA2Y; Fri, 7 Jan 2022 01:07:13 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1130249F4B; Fri, 7 Jan 2022 01:07:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AAC8249F4B for ; Fri, 7 Jan 2022 01:07:11 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL2-80vcmH-1 for ; Fri, 7 Jan 2022 01:07:10 -0500 (EST) Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 96D4D49EE4 for ; Fri, 7 Jan 2022 01:07:10 -0500 (EST) Received: by mail-pj1-f43.google.com with SMTP id y16-20020a17090a6c9000b001b13ffaa625so10980409pjj.2 for ; Thu, 06 Jan 2022 22:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2q58XOryfIlXBk+Ga94YK5KAiqVRv5tmtrlFtSkfC0E=; b=ochKJUmv9jcYYqjl8Ri0yXzDhwacQ2/M9JFDOvS2FBy8XLGNBzhfSvKLa9ii/FgSHR lKXPiHPPHOi42VPVoABzyceIiJ8F+Kbs3IS0k75hH2A5mdF2XigOH5lmdKWrpcwtxdbr ezxvlB8NX6lqdXgr7vLxp+V4EZIGdh1LCkEFmJztS6KTyCd2fXWSEdqhhi3oBwVmS13w /pYkJOH9knWKKZPd/LGxDD94eatNe6H5EBW+iGlQr71hEgAmZVB6ZiK24VPUj2ooMIaj 42ZKBZFHvnOHD474TolWmS+OmhGNji04Be9HsERGLppfG0rRjME6jGJDuXtYXGuWgZIu K72Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2q58XOryfIlXBk+Ga94YK5KAiqVRv5tmtrlFtSkfC0E=; b=oWXkADpva0rcZUDN92pONKUKYaXNfSO6iCf7MdzK74Kw0k9mhAxrZOOeaq4WUkxq9e G2ewnEAJxGNIXZHUXIob0QJj5KjFdHY7vqiLQX6JyHrdern62pIFb5NSuisheWwEXDUb L6K9Gtfivkirk2UmULL8usnvnMVX+ogriyr41eDgJZTBYanAzj3REXlccdlldsDhUt+B J6j4CbzZkQRsuF3Z033O3hjrYRca6rmFDsWAFNAoJnMYeSY5UPdkhSfyUDTS4r5F+ZPb 8zGS2QKtfRbf4lvnKH9BoKyUKUxGGPD8Tfd6mjDEKQuPhx793sFuMDh2KWB1asZHUdiA pfmA== X-Gm-Message-State: AOAM531SjuVYL7x6A0VvwrnR/eMySPgcCw5w4UbL48fN0wp89JYRpuJ9 u2t4Z3Je0Y6KiFT9b73hNzoKhGfno+r5lReBhYkCOg== X-Google-Smtp-Source: ABdhPJzi8RhMHj39b+4Rn0KshD189vXaFIX2vj8EwamLndmdEQUpG8o9KUsh8L5L/q0EpOVykikO8FcKUk+BveZguG8= X-Received: by 2002:a17:902:c652:b0:148:f1a5:b7bf with SMTP id s18-20020a170902c65200b00148f1a5b7bfmr62134703pls.122.1641535629407; Thu, 06 Jan 2022 22:07:09 -0800 (PST) MIME-Version: 1.0 References: <20220104194918.373612-1-rananta@google.com> <20220104194918.373612-2-rananta@google.com> In-Reply-To: <20220104194918.373612-2-rananta@google.com> From: Reiji Watanabe Date: Thu, 6 Jan 2022 22:06:53 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Raghavendra Rao Ananta Cc: kvm@vger.kernel.org, Will Deacon , Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Raghu, On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta wrote: > > Capture the start of the KVM VM, which is basically the > start of any vCPU run. This state of the VM is helpful > in the upcoming patches to prevent user-space from > configuring certain VM features after the VM has started > running. > > Signed-off-by: Raghavendra Rao Ananta > --- > include/linux/kvm_host.h | 3 +++ > virt/kvm/kvm_main.c | 9 +++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index c310648cc8f1..d0bd8f7a026c 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -623,6 +623,7 @@ struct kvm { > struct notifier_block pm_notifier; > #endif > char stats_id[KVM_STATS_NAME_SIZE]; > + bool vm_started; Since KVM_RUN on any vCPUs doesn't necessarily mean that the VM started yet, the name might be a bit misleading IMHO. I would think 'has_run_once' or 'ran_once' might be more clear (?). > }; > > #define kvm_err(fmt, ...) \ > @@ -1666,6 +1667,8 @@ static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu) > } > } > > +#define kvm_vm_has_started(kvm) (kvm->vm_started) > + > extern bool kvm_rebooting; > > extern unsigned int halt_poll_ns; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 72c4e6b39389..962b91ac2064 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3686,6 +3686,7 @@ static long kvm_vcpu_ioctl(struct file *filp, > int r; > struct kvm_fpu *fpu = NULL; > struct kvm_sregs *kvm_sregs = NULL; > + struct kvm *kvm = vcpu->kvm; > > if (vcpu->kvm->mm != current->mm || vcpu->kvm->vm_dead) > return -EIO; > @@ -3723,6 +3724,14 @@ static long kvm_vcpu_ioctl(struct file *filp, > if (oldpid) > synchronize_rcu(); > put_pid(oldpid); > + > + /* > + * Since we land here even on the first vCPU run, > + * we can mark that the VM has started running. > + */ It might be nicer to add a comment why the code below gets kvm->lock. Anyway, the patch generally looks good to me, and thank you for making this change (it works for my purpose as well). Reviewed-by: Reiji Watanabe Thanks, Reiji > + mutex_lock(&kvm->lock); > + kvm->vm_started = true; > + mutex_unlock(&kvm->lock); > } > r = kvm_arch_vcpu_ioctl_run(vcpu); > trace_kvm_userspace_exit(vcpu->run->exit_reason, r); > -- > 2.34.1.448.ga2b2bfdf31-goog > _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0EB79C433F5 for ; Fri, 7 Jan 2022 06:08:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=724IdPpohuamXvjTifcMQs2QCfWIg1oZL4br+hkw2bk=; b=p2/mWAYgp0ghB0 +0QtFQ0smMgRiNx9z8YbiuaLiSMP/2Zb2gnrXR6VtH4gbEukBq5bsniqAKGDxwkiPeQgONmgcVIOv EzT/4y5ithonY+v+d8I8fTBzjZ+dWV+NmYealpLo6kDuKLHxODvcqjEBvn+khXolgyGy3OpA9Uqjk Q6JC/c094nMc08D3i8242sxIWtOIctaRZK0odVsJUE53W/epgd7LuL/fQ+FwiXHdMw9ZKsntTDFdM 59A87Uxg1TLkIV3vgeqjLp+45UXxUDg4zZzr2FqeclHXftBo1XY3swNIrQS7khwdyfFH2aJssM8lH nXhzxmgPa6FWpXdBHEKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5iPF-002ZKt-9q; Fri, 07 Jan 2022 06:07:17 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5iPB-002ZJj-P6 for linux-arm-kernel@lists.infradead.org; Fri, 07 Jan 2022 06:07:15 +0000 Received: by mail-pj1-x102c.google.com with SMTP id l10-20020a17090a384a00b001b22190e075so10939048pjf.3 for ; Thu, 06 Jan 2022 22:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2q58XOryfIlXBk+Ga94YK5KAiqVRv5tmtrlFtSkfC0E=; b=ochKJUmv9jcYYqjl8Ri0yXzDhwacQ2/M9JFDOvS2FBy8XLGNBzhfSvKLa9ii/FgSHR lKXPiHPPHOi42VPVoABzyceIiJ8F+Kbs3IS0k75hH2A5mdF2XigOH5lmdKWrpcwtxdbr ezxvlB8NX6lqdXgr7vLxp+V4EZIGdh1LCkEFmJztS6KTyCd2fXWSEdqhhi3oBwVmS13w /pYkJOH9knWKKZPd/LGxDD94eatNe6H5EBW+iGlQr71hEgAmZVB6ZiK24VPUj2ooMIaj 42ZKBZFHvnOHD474TolWmS+OmhGNji04Be9HsERGLppfG0rRjME6jGJDuXtYXGuWgZIu K72Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2q58XOryfIlXBk+Ga94YK5KAiqVRv5tmtrlFtSkfC0E=; b=fkSac4EdXek7OwpcqZlgKOl1nZIe0iLg6NisbF8ZksUIXpPLjR82sdxSrKP8OkcmN/ 1jSV9iZrp+cp6xQ0pZa47+T7eYMsC0MjD4Hf2r1Ck9tkoOmvTKg3q6MkRNNA//Kem5Z5 52QaRpFJyR7eMVnh6SknhfT0LI6T3mvtUhWjaMdBmcXvrOa6G2B3t+Npia4KDhXsvUt+ nvJktS/ZwahTyXV9ywm8fOybhpp84gxdjMs1TVkzQJfbyyFet54gxMyhrzxziBXFhC11 jsL5UtJjjGIGzlWYN3YBebRgtHQ0FVtt4yEPKfoYrWkMRAXKe6GD+Ax1k49/+s7raAIZ lxiA== X-Gm-Message-State: AOAM530Lv7+o3mVJPhJRghFZEUDYtW6IjNpNhotENy4DvA8aiX5ESaNv H1l8QKTPEqC9kxbgAAn7/FL7NBoKN/wbwzuGo7q4aA== X-Google-Smtp-Source: ABdhPJzi8RhMHj39b+4Rn0KshD189vXaFIX2vj8EwamLndmdEQUpG8o9KUsh8L5L/q0EpOVykikO8FcKUk+BveZguG8= X-Received: by 2002:a17:902:c652:b0:148:f1a5:b7bf with SMTP id s18-20020a170902c65200b00148f1a5b7bfmr62134703pls.122.1641535629407; Thu, 06 Jan 2022 22:07:09 -0800 (PST) MIME-Version: 1.0 References: <20220104194918.373612-1-rananta@google.com> <20220104194918.373612-2-rananta@google.com> In-Reply-To: <20220104194918.373612-2-rananta@google.com> From: Reiji Watanabe Date: Thu, 6 Jan 2022 22:06:53 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Raghavendra Rao Ananta Cc: Marc Zyngier , Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Linux ARM , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220106_220713_883970_68B4F1BA X-CRM114-Status: GOOD ( 22.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Raghu, On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta wrote: > > Capture the start of the KVM VM, which is basically the > start of any vCPU run. This state of the VM is helpful > in the upcoming patches to prevent user-space from > configuring certain VM features after the VM has started > running. > > Signed-off-by: Raghavendra Rao Ananta > --- > include/linux/kvm_host.h | 3 +++ > virt/kvm/kvm_main.c | 9 +++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index c310648cc8f1..d0bd8f7a026c 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -623,6 +623,7 @@ struct kvm { > struct notifier_block pm_notifier; > #endif > char stats_id[KVM_STATS_NAME_SIZE]; > + bool vm_started; Since KVM_RUN on any vCPUs doesn't necessarily mean that the VM started yet, the name might be a bit misleading IMHO. I would think 'has_run_once' or 'ran_once' might be more clear (?). > }; > > #define kvm_err(fmt, ...) \ > @@ -1666,6 +1667,8 @@ static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu) > } > } > > +#define kvm_vm_has_started(kvm) (kvm->vm_started) > + > extern bool kvm_rebooting; > > extern unsigned int halt_poll_ns; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 72c4e6b39389..962b91ac2064 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3686,6 +3686,7 @@ static long kvm_vcpu_ioctl(struct file *filp, > int r; > struct kvm_fpu *fpu = NULL; > struct kvm_sregs *kvm_sregs = NULL; > + struct kvm *kvm = vcpu->kvm; > > if (vcpu->kvm->mm != current->mm || vcpu->kvm->vm_dead) > return -EIO; > @@ -3723,6 +3724,14 @@ static long kvm_vcpu_ioctl(struct file *filp, > if (oldpid) > synchronize_rcu(); > put_pid(oldpid); > + > + /* > + * Since we land here even on the first vCPU run, > + * we can mark that the VM has started running. > + */ It might be nicer to add a comment why the code below gets kvm->lock. Anyway, the patch generally looks good to me, and thank you for making this change (it works for my purpose as well). Reviewed-by: Reiji Watanabe Thanks, Reiji > + mutex_lock(&kvm->lock); > + kvm->vm_started = true; > + mutex_unlock(&kvm->lock); > } > r = kvm_arch_vcpu_ioctl_run(vcpu); > trace_kvm_userspace_exit(vcpu->run->exit_reason, r); > -- > 2.34.1.448.ga2b2bfdf31-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel