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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCA20C4360F for ; Tue, 2 Apr 2019 09:32:52 +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 AC1832082C for ; Tue, 2 Apr 2019 09:32:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Fw7BGtgQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC1832082C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=m1LgyNdiiB7SeQ48X1xVEkpXiHomFhTrDPrWXTm60ws=; b=Fw7BGtgQXDSiwC Qzke+f7yngbNc8/wJbqxWnwlfUq+wkYrl5rtcI4Fz9uI2XE1xQZiHS4VaEdUg1wJZ69m994cvXH0u cSrDEmc6UWNcXFXvVgAhaqvp/OlxiHHuQ+CdF3tmrcLJJTvOcIiXXzFlTufI85ABA88f/XqyjwEqG wM1z8aenujspsfF7A/GNXtCMgXM8Gl9EWo/LIQ1j2WX+miupwyS/GmtUW6A8LEB2zZw/3fP+yucYb nTH62z9t7Y1mkq1uHR0MBm2HNqZWHOjnkt6amV0z9yOar4bQZRo0qOiiY/2e+Vx1jL/90wikCKxNq 3K4zNuTFvKeEk+BqjTGw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBFmh-0007X8-9S; Tue, 02 Apr 2019 09:32:47 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBFmd-0007Wm-9d for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2019 09:32:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7BD1580D; Tue, 2 Apr 2019 02:32:41 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BBE6D3F59C; Tue, 2 Apr 2019 02:32:37 -0700 (PDT) Date: Tue, 02 Apr 2019 10:32:34 +0100 Message-ID: <865zrw69cd.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Dave Martin Subject: Re: [PATCH v7 16/27] KVM: arm64: Factor out core register ID enumeration In-Reply-To: <20190402085917.GF3567@e103592.cambridge.arm.com> References: <1553864452-15080-1-git-send-email-Dave.Martin@arm.com> <1553864452-15080-17-git-send-email-Dave.Martin@arm.com> <86ftr15dsb.wl-marc.zyngier@arm.com> <20190402085917.GF3567@e103592.cambridge.arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190402_023243_350153_E001F979 X-CRM114-Status: GOOD ( 37.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Okamoto Takayuki , Christoffer Dall , Ard Biesheuvel , Catalin Marinas , Will Deacon , Zhang Lei , Julien Grall , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 02 Apr 2019 09:59:19 +0100, Dave Martin wrote: > > On Tue, Apr 02, 2019 at 03:41:56AM +0100, Marc Zyngier wrote: > > On Fri, 29 Mar 2019 13:00:41 +0000, > > Dave Martin wrote: > > > > > > In preparation for adding logic to filter out some KVM_REG_ARM_CORE > > > registers from the KVM_GET_REG_LIST output, this patch factors out > > > the core register enumeration into a separate function and rebuilds > > > num_core_regs() on top of it. > > > > > > This may be a little more expensive (depending on how good a job > > > the compiler does of specialising the code), but KVM_GET_REG_LIST > > > is not a hot path. > > > > > > This will make it easier to consolidate ID filtering code in one > > > place. > > > > > > No functional change. > > > > > > Signed-off-by: Dave Martin > > > Reviewed-by: Julien Thierry > > > Tested-by: zhang.lei > > > > > > --- > > > > > > Changes since v5: > > > > > > * New patch. > > > > > > This reimplements part of the separately-posted patch "KVM: arm64: > > > Factor out KVM_GET_REG_LIST core register enumeration", minus aspects > > > that potentially break the ABI. > > > > > > As a result, the opportunity to truly consolidate all the ID reg > > > filtering in one place is deliberately left on the floor, for now. > > > This will be addressed in a separate series later on. > > > --- > > > arch/arm64/kvm/guest.c | 33 +++++++++++++++++++++++++-------- > > > 1 file changed, 25 insertions(+), 8 deletions(-) > > > > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > > > index 3e38eb2..a391a61 100644 > > > --- a/arch/arm64/kvm/guest.c > > > +++ b/arch/arm64/kvm/guest.c > > [...] > > > > @@ -276,15 +296,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu) > > > */ > > > int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) > > > { > > > - unsigned int i; > > > - const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE; > > > int ret; > > > > > > - for (i = 0; i < sizeof(struct kvm_regs) / sizeof(__u32); i++) { > > > - if (put_user(core_reg | i, uindices)) > > > - return -EFAULT; > > > - uindices++; > > > - } > > > + ret = kvm_arm_copy_core_reg_indices(uindices); > > > + if (ret) > > > + return ret; > > > + uindices += ret; > > > > Interesting snippet. Given that most implementations have at least one > > register, this can hardly work. Please do test things with QEMU, and > > not only kvmtool which obviously doesn't exercise this path. > > My bad: this used to work to do the right thing, but I broke it when > splitting up [1] for v6 to avoid the dependency. > > kvm_arm_copy_core_reg_indices() used to take &uindices and update it > directly, returning 0 on success instead of the number of registers. > But this seemed less consistent with the way the other functions are > called. > > > For the sake of getting -next back to a vaguely usable state, I've now > > queued the following patch on top. > > > > M. > > > > From 832401c8912680ee56dc5cb6ab101266b3db416a Mon Sep 17 00:00:00 2001 > > From: Marc Zyngier > > Date: Tue, 2 Apr 2019 03:28:39 +0100 > > Subject: [PATCH] arm64: KVM: Fix system register enumeration > > > > The introduction of the SVE registers to userspace started with a > > refactoring of the way we expose any register via the ONE_REG > > interface. > > > > Unfortunately, this change doesn't exactly behave as expected > > if the number of registers is non-zero and consider everything > > to be an error. The visible result is that QEMU barfs very early > > when creating vcpus. > > > > Make sure we only exit early in case there is an actual error, rather > > than a positive number of registers... > > > > be25bbb392fa ("KVM: arm64: Factor out core register ID enumeration") > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/guest.c | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > > index 086ab0508d69..4f7b26bbf671 100644 > > --- a/arch/arm64/kvm/guest.c > > +++ b/arch/arm64/kvm/guest.c > > @@ -604,22 +604,22 @@ int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) > > int ret; > > > > ret = copy_core_reg_indices(vcpu, uindices); > > - if (ret) > > + if (ret < 0) > > return ret; > > uindices += ret; > > > > ret = copy_sve_reg_indices(vcpu, uindices); > > - if (ret) > > + if (ret < 0) > > return ret; > > uindices += ret; > > ^ Ack > > > ret = kvm_arm_copy_fw_reg_indices(vcpu, uindices); > > - if (ret) > > + if (ret < 0) > > return ret; > > uindices += kvm_arm_get_fw_num_regs(vcpu); > > > > ret = copy_timer_indices(vcpu, uindices); > > - if (ret) > > + if (ret < 0) > > return ret; > > uindices += NUM_TIMER_REGS; > > For these two, the interface is not really the same. These don't > return the number of registers, so return 0 on success. "< 0" here > could be a trap for the future, though the risk looks low. I realised that, but since they all return a negative value on error, I went for a similar error handling. > I can have a go at some rework on top to make this more consistent, > but I'd rather not muddy the water further for the moment. > > Any view on that? I don't think there is any urgency on that front. For now, I'd like to make sure things do not regress. Once we're sure we have something stable, we'll be able to make it shiny. Thanks, M. -- Jazz is not dead, it just smell funny. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel