From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 836A2282FA for ; Thu, 13 Mar 2025 15:37:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741880237; cv=none; b=aHUgLcXSwvqRX3wGVtl2eJ0X/EVpuGUjQFhDx1fcKFGSuxTKFfhBWF9UknIiR64DLXTWluJGYCxhxKv+8Mjr8Z6YWQzpPEq8VHYicWJX/kNG+7Xui/SdGf/c4D6fctWN9Ls/HGY8ei/I297dCxQNYoChxYiV/kMxL+HnBPZ+fGU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741880237; c=relaxed/simple; bh=lj70Vcf5P1FiVkunK6lCCECN3JyROdomusxRD8izs84=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=d//qbVcA90o3+4Fop5WIQN6eWuW4g+4bq14dHBWHIBT1BPf6B8ZliJBPphCMmy4vyfmgdzkfoLZmIBF4WNvEy6rkd/soiuDTHA9+akbua5UpnCDDOdptNgjBVF1xhrDblIW80YbP9Ur4tL0zyd5Y1gK1AKFb8hiqPaXXtH7gsY0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 24E5A1477; Thu, 13 Mar 2025 08:37:26 -0700 (PDT) Received: from raptor (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B6F9F3F694; Thu, 13 Mar 2025 08:37:14 -0700 (PDT) Date: Thu, 13 Mar 2025 15:37:12 +0000 From: Alexandru Elisei To: "Aneesh Kumar K.V (Arm)" Cc: kvm@vger.kernel.org, Suzuki K Poulose , Steven Price , Will Deacon , Julien Thierry Subject: Re: [PATCH kvmtool v2 1/2] cpu: vmexit: Handle KVM_EXIT_UNKNOWN exit reason correctly Message-ID: References: <20250224091000.3925918-1-aneesh.kumar@kernel.org> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250224091000.3925918-1-aneesh.kumar@kernel.org> Hi Aneesh, On Mon, Feb 24, 2025 at 02:39:59PM +0530, Aneesh Kumar K.V (Arm) wrote: > The return value for kernel VM exit handlers is confusing and has led to > errors in different kernel exit handlers. A return value of 0 indicates > a return to the VMM, whereas a return value of 1 indicates resuming > execution in the guest. Some handlers mistakenly return 0 to force a > return to the guest. > > This worked in kvmtool because the exit_reason defaulted to > 0 (KVM_EXIT_UNKNOWN), and kvmtool did not error out on an unknown exit > reason. However, forcing a VMM exit with error on KVM_EXIT_UNKNOWN > exit_reson would help catch these bugs early. I think I understand what you're saying - if there's a bug in handle_exit() in KVM that triggers an erroneous exit to userspace, exit_reason and the exit information struct could still be at their default values, which are 0 from when kvm_run was allocated (in kvm_vm_ioctl_create_vcpu()). An exit_reason of 0 is interpreted by userspace as KVM_EXIT_UNKNOWN, but kvmtool on KVM_EXIT_UNKNOWN resumes the guest instead of signalling the error, thus masking the buggy KVM behaviour. The patch looks good to me: Reviewed-by: Alexandru Elisei Thanks, Alex > > Signed-off-by: Aneesh Kumar K.V (Arm) > --- > kvm-cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kvm-cpu.c b/kvm-cpu.c > index f66dcd07220c..7c62bfc56679 100644 > --- a/kvm-cpu.c > +++ b/kvm-cpu.c > @@ -170,7 +170,7 @@ int kvm_cpu__start(struct kvm_cpu *cpu) > > switch (cpu->kvm_run->exit_reason) { > case KVM_EXIT_UNKNOWN: > - break; > + goto panic_kvm; > case KVM_EXIT_DEBUG: > kvm_cpu__show_registers(cpu); > kvm_cpu__show_code(cpu); > -- > 2.43.0 >