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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEA99C433EF for ; Thu, 4 Nov 2021 16:35:40 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C164461213 for ; Thu, 4 Nov 2021 16:35:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C164461213 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rcq68FYixpxY4No5Cqlh5R+4pzt3ZrEKxIGwF3fFd/Y=; b=QBQz8guhkCo32D Y/X27RhZNx1POmjIFEb16kyplxfchw/29HmFOc5NNSXC52nCHnCW1eC0h4OdkWyXtwHWhm7ACZ7d6 9G0TGbkVzguiJu+jB/kHCDnz1SDS4leQkeKx9AFOFxrzAfRWJUyNJLoJctgyYuBbIVroiKgpbCOYo gi2E+N8cxD6l53UVrVQccK7FemUP5jvkfgd8sjCpcPB3snypOpJAm6XM0dZl+p0eC4Bkhyu0EarL5 uezbvmqpeRIJawViahms3AtKUKsxI08Qz8m7ZE0iTRrhge4uzBEKcJCkB77ifUk/pUQgRDy1uyY+Q FqI3hCUKYc1GBh/mzUQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mifgm-009Uiz-EB; Thu, 04 Nov 2021 16:34:08 +0000 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mifgi-009UiC-0B for linux-arm-kernel@lists.infradead.org; Thu, 04 Nov 2021 16:34:05 +0000 Received: by mail-il1-x134.google.com with SMTP id l8so6792384ilv.3 for ; Thu, 04 Nov 2021 09:34:03 -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=q1yu7/PiEk97jw7ubKDogFhwFOEgMTEG87VVKJNSDwY=; b=EmOtiopjfneALNBRoVKWdawMl2M3KkYtZiMbYTbeoSRNPxNFamFJB15UGYz5w2SI0V kS6SMvi0/7oAX0/I8ZpuwQzXHak5mm+OqBWONBBZEvsbl38UD16F4Oxm6NZUOfILYPev D8nE6nibTuyBs+B07ZBC8kxTRG/bM+Hb4xwNQ+WfUsrK2/bYav2KZYxxd0hk9OeuTBmm vJffFoDaTHslbMOF0C/QKV4V64g0kvK4dIVATns44Wo6qOJ2TSDNLlNUwGRUOqlhBY/l yMtMsM8rami0HJCsSdD8bRWAZK2iXVxVjCivrjdV1RQPcULQViCSUIojiNUVagaYvIsA ++bw== 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=q1yu7/PiEk97jw7ubKDogFhwFOEgMTEG87VVKJNSDwY=; b=TRR6uje6TVSs6NXgMBKo3yaOBgnoDQHU0yh4VvLAGODzmiv0zhx5OeO96oCTXAl6bJ 4aALwgJE5oP5/L2yN1ubzy77oivhmZtL06Kd15AJEJKJf26tzth491aDSG/ZXH4AanhC thjCrI7Sj+QP9yuTo+Zh0y1wzgr1QiyJ2paw8Tz92WPwGKiFd9aNfnPrDjncevAentIG U4mJCZSaZzfxQrHAw+drz8YTbldGwUh2IO6mM9RSfRdk2XoQYjw063QTnqz1jI312jnv gaowoUW2bARcmSeTcKa0E3JYBmfFVzXjb8EGb+fdHA5yA9aJZ5fvSK0MaYUsCrkrBGl1 1ZeA== X-Gm-Message-State: AOAM531B3aieGr9t9rLBFWbjiA1bR3ymAuQpse4R3f7KLHFhN5nGlOkj vx0Xi6spDUHqJhfjREiS3dcNwQ== X-Google-Smtp-Source: ABdhPJw21oNXW5cMVRe+U/gVxiAeINDXbZ00FJbMCyzm7P2yY2n2xfR22DKFXu21MwzMG+ENi/zSnQ== X-Received: by 2002:a92:c80d:: with SMTP id v13mr36807785iln.175.1636043642354; Thu, 04 Nov 2021 09:34:02 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id z6sm2930080ioq.35.2021.11.04.09.34.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Nov 2021 09:34:01 -0700 (PDT) Date: Thu, 4 Nov 2021 16:33:58 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [RFC PATCH v2 04/28] KVM: arm64: Keep consistency of ID registers between vCPUs Message-ID: References: <20211103062520.1445832-1-reijiw@google.com> <20211103062520.1445832-5-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211103062520.1445832-5-reijiw@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_093404_071564_7237F608 X-CRM114-Status: GOOD ( 28.81 ) 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 On Tue, Nov 02, 2021 at 11:24:56PM -0700, Reiji Watanabe wrote: > All vCPUs that are owned by a VM must have the same values of ID > registers. > > Return an error at the very first KVM_RUN for a vCPU if the vCPU has > different values in any ID registers from any other vCPUs that have > already started KVM_RUN once. Also, return an error if userspace > tries to change a value of ID register for a vCPU that already > started KVM_RUN once. > > Changing ID register is still not allowed at present though. > > Signed-off-by: Reiji Watanabe > --- > arch/arm64/include/asm/kvm_host.h | 2 ++ > arch/arm64/kvm/arm.c | 4 ++++ > arch/arm64/kvm/sys_regs.c | 31 +++++++++++++++++++++++++++++++ > 3 files changed, 37 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 0cd351099adf..69af669308b0 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -745,6 +745,8 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu, > long kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm, > struct kvm_arm_copy_mte_tags *copy_tags); > > +int kvm_id_regs_consistency_check(const struct kvm_vcpu *vcpu); > + > /* Guest/host FPSIMD coordination helpers */ > int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu); > void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu); > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index fe102cd2e518..83cedd74de73 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -595,6 +595,10 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu) > return -EPERM; > > vcpu->arch.has_run_once = true; > + if (kvm_id_regs_consistency_check(vcpu)) { > + vcpu->arch.has_run_once = false; > + return -EPERM; > + } It might be nice to return an error to userspace synchronously (i.e. on the register write). Of course, there is still the issue where userspace writes to some (but not all) of the vCPU feature ID registers, which can't be known until the first KVM_RUN. > > kvm_arm_vcpu_init_debug(vcpu); > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 64d51aa3aee3..e34351fdc66c 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1436,6 +1436,10 @@ static int __set_id_reg(struct kvm_vcpu *vcpu, > if (val != read_id_reg(vcpu, rd, raz) && !GET_ID_REG_INFO(encoding)) > return -EINVAL; > > + /* Don't allow to change the reg after the first KVM_RUN. */ > + if (vcpu->arch.has_run_once) > + return -EINVAL; > + > if (raz) > return 0; > > @@ -3004,6 +3008,33 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) > return write_demux_regids(uindices); > } > > +int kvm_id_regs_consistency_check(const struct kvm_vcpu *vcpu) > +{ > + int i; > + const struct kvm_vcpu *t_vcpu; > + > + /* > + * Make sure vcpu->arch.has_run_once is visible for others so that > + * ID regs' consistency between two vCPUs is checked by either one > + * at least. > + */ > + smp_mb(); > + WARN_ON(!vcpu->arch.has_run_once); > + > + kvm_for_each_vcpu(i, t_vcpu, vcpu->kvm) { > + if (!t_vcpu->arch.has_run_once) > + /* ID regs still could be updated. */ > + continue; > + > + if (memcmp(&__vcpu_sys_reg(vcpu, ID_REG_BASE), > + &__vcpu_sys_reg(t_vcpu, ID_REG_BASE), > + sizeof(__vcpu_sys_reg(vcpu, ID_REG_BASE)) * > + KVM_ARM_ID_REG_MAX_NUM)) > + return -EINVAL; > + } > + return 0; > +} > + Couldn't we do the consistency check exactly once per VM? I had alluded to this when reviewing Raghu's patches, but I think the same applies here too: an abstraction for detecting the first vCPU to run in a VM. https://lore.kernel.org/all/YYMKphExkqttn2w0@google.com/ -- Thanks Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel