From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CF81302777 for ; Fri, 5 Dec 2025 10:23:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764930225; cv=none; b=Lah0fZzJfboNN3Vp7edxC37HRNxBqQM2tUoogbRJGP+PLpmNQTT8TSQwNnYVAJhfbsEwrtBZDIm+z1/cjVf+TmwtapbeDOTbcVlHBamjRp5FKpvOaTpr7ygJhyaLh++tT4Qr1WbEuukO4YkjrjeADZfkkXWqnT8CXFkHQ0zQh5A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764930225; c=relaxed/simple; bh=pwhFHjvbxOJ6MCXdhz6if7uY6B/UT86ioPoRTaBLukY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=KwFeP8dqeE+5Acx9CVM9jldP0hvXqj7CqTOWQkvi8QVOlbcOXlScD/cgc8RgS2wTnB1Fnxfnb/AD5SnVgWhWVvlDCNAY6ZWZd265mJqbseUbdAc+OUiE2ykriVP06UDnFv3hQ0Qmfz8aCGNxm7W6czGHlCgerktoeq9h4arkn40= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eGuFpF9c; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=BB46jHb4; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eGuFpF9c"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="BB46jHb4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1764930214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6xW6jefNHPNF0bpweUbMnSI3U9B7pAKO05hs1H2bEbQ=; b=eGuFpF9ct6F4ZqOGGbJxXt6pTzufnwwmTn8lkAiGSE2kH+BkKwaZVXrV4eIk0MbzmAgPEy SUhZU9h9KqFpeQ3PJrFotNuRHjtiUkBV02wOh4GgxC+42OTncq7g5D0CQ0f85mH6WZaCHA VpzvtVKEG5oOO3fgDywwQUjT5Of7YpI= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-101-fGT2cN82NlKOnSfsyJx2jA-1; Fri, 05 Dec 2025 05:23:33 -0500 X-MC-Unique: fGT2cN82NlKOnSfsyJx2jA-1 X-Mimecast-MFC-AGG-ID: fGT2cN82NlKOnSfsyJx2jA_1764930212 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-42e2e50cfaeso1955848f8f.3 for ; Fri, 05 Dec 2025 02:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1764930212; x=1765535012; darn=vger.kernel.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=6xW6jefNHPNF0bpweUbMnSI3U9B7pAKO05hs1H2bEbQ=; b=BB46jHb4HogsoGqVSNkfbXIa3P6Iwuu36gdj8zUv2XgilSMQMOo5FaC2h+hPk8TqZH xsCIECk5Mv3tVQcrbSM4MlcoxTLPkpKzaPTdoUp5NeY2j9jNyFOKUrVF2wOUL646KLrT nCnbek5zQMiTdvi4duhYSoNt9v8LUeTr8MQ32T4BT7ZxvUhZT5s4D1YEhk6LeZZ09h1b aP02HETqUTfNIACscIyrxUNXFu6tpHpHursZXq/2lFjpGD1Caaz1nGWStw5EaBPOGQKP mSBJ3G0UxCzk5Qb5/46WfqowX8UM3vkyVMEn7ofunuOEYB7aeF0qeEof9HPUg3SMa+kh nRTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764930212; x=1765535012; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6xW6jefNHPNF0bpweUbMnSI3U9B7pAKO05hs1H2bEbQ=; b=pOVyqlXz5pemfYPhfeqR5/jZsrhAHzqqDOENvuQgf+gVBUnjCv2YUS6CBCKuq8h6ST 2Cs/BjFeZ1XqL4lb/xTProdFScwshEX+3Kx7weUAfNu05hhUJ0Og4Aq4rNMJ53iEWH/m nMuVn3B2NjrihYPeWGTFhLqIeBcEIDUvFa3TdPTO8RcODBb+adRpjn8ny3rEiqjVYTW5 YFKDNlCv7kYb2akIRMAyrzh3MJF1CRYxacLilRNLfp6S2iD331dqbksuF0B3MEpdNvCn KMLFOMfV0KfppVfJPlqQsg4OPsQVH6Jzje54gDxeR+YVbfUVlUw0yBEf3hUe8JNl8Qq7 llxg== X-Forwarded-Encrypted: i=1; AJvYcCW+dHZ5mF5/0XpwiWeS1ZiRbjBWGyk10XMFKaThg5zhC5BJ/4aSppVaofRGpcle7ZxRX4UqTLUCX2W69G4=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4DZDy8OewumzO6C9cfsSvoHTLcMPa5Fzp3VSXPre1IXbceoAH zaa9c/mnJrXC4c/wfv1uYYCR29UsauFXBrs/8X2EePx50+il3rykfXrIASZ//qDUGVUJQ7RE8WM nSmHt7QSBotvOCiLpskDAPJWVKHFVEzyyDbyjFBrKHJpAj8VwGt2vrJ5KCbwkqZA0RJ4P7t5MgA == X-Gm-Gg: ASbGncuDU/j7uE/+GbGhKk8JuO0OvIzw6s3KDfg4uIPalxBWNf2d5rd0Nxl/rMlCBjd Yn9Bgav7KE72V0I3Y0TPryXcSPnU4TJv6Pw2qahr3NhOK9IEnYgzEsJW+C3IOKhgl26j01o//hx zmsCiszHSPv6g3h5I+OuyU20XsuuQokuSIZPrfHkNiIbQgk3cHpqUy3y07ngd5I5CwGn9r1YRfg 5M1c6STfua1xYGr54DVg6h6O+dI57+mBeGTFfB+Idd5yqQL9fEdsDGIDM/o3vcBgS/qnIqLimIC B8RnzJ3UGqxy438EtX9UTD5enwnpeLoJAGAkrTeSZFH0IgfmyRmB2B57/Fa4OXSrlgoqYnhSId7 LCe3aEA== X-Received: by 2002:a05:6000:40c7:b0:428:4354:aa26 with SMTP id ffacd0b85a97d-42f79851e8amr6654635f8f.47.1764930211967; Fri, 05 Dec 2025 02:23:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IHrdOemlWNGUF6CbfSfufhv59m+zQeQwV6PzBv0W7dgch4smDWMT4zUpBoGQijXrByxYlVabg== X-Received: by 2002:a05:6000:40c7:b0:428:4354:aa26 with SMTP id ffacd0b85a97d-42f79851e8amr6654598f8f.47.1764930211455; Fri, 05 Dec 2025 02:23:31 -0800 (PST) Received: from fedora (g3.ign.cz. [91.219.240.17]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7d331e29sm8310163f8f.32.2025.12.05.02.23.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Dec 2025 02:23:30 -0800 (PST) From: Vitaly Kuznetsov To: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org Cc: Juergen Gross , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: Re: [PATCH 05/10] KVM/x86: Add KVM_MSR_RET_* defines for values 0 and 1 In-Reply-To: <20251205074537.17072-6-jgross@suse.com> References: <20251205074537.17072-1-jgross@suse.com> <20251205074537.17072-6-jgross@suse.com> Date: Fri, 05 Dec 2025 11:23:29 +0100 Message-ID: <877bv1kz1a.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Juergen Gross writes: > For MSR emulation return values only 2 special cases have defines, > while the most used values 0 and 1 don't. > > Reason seems to be the maze of function calls of MSR emulation > intertwined with the KVM guest exit handlers, which are using the > values 0 and 1 for other purposes. This even led to the comment above > the already existing defines, warning to use the values 0 and 1 (and > negative errno values) in the MSR emulation at all. > > Fact is that MSR emulation and exit handlers are in fact rather well > distinct, with only very few exceptions which are handled in a sane > way. > > So add defines for 0 and 1 values of MSR emulation and at the same > time comments where exit handlers are calling into MSR emulation. > > The new defines will be used later. > > No change of functionality intended. > > Signed-off-by: Juergen Gross > --- > arch/x86/kvm/x86.c | 2 ++ > arch/x86/kvm/x86.h | 10 ++++++++-- > 2 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index e733cb923312..e87963a47aa5 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -2130,6 +2130,7 @@ static int __kvm_emulate_rdmsr(struct kvm_vcpu *vcpu, u32 msr, int reg, > u64 data; > int r; > > + /* Call MSR emulation. */ > r = kvm_emulate_msr_read(vcpu, msr, &data); > > if (!r) { > @@ -2171,6 +2172,7 @@ static int __kvm_emulate_wrmsr(struct kvm_vcpu *vcpu, u32 msr, u64 data) > { > int r; > > + /* Call MSR emulation. */ > r = kvm_emulate_msr_write(vcpu, msr, data); > if (!r) { > trace_kvm_msr_write(msr, data); > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h > index f3dc77f006f9..e44b6373b106 100644 > --- a/arch/x86/kvm/x86.h > +++ b/arch/x86/kvm/x86.h > @@ -639,15 +639,21 @@ enum kvm_msr_access { > /* > * Internal error codes that are used to indicate that MSR emulation encountered > * an error that should result in #GP in the guest, unless userspace handles it. > - * Note, '1', '0', and negative numbers are off limits, as they are used by KVM > - * as part of KVM's lightly documented internal KVM_RUN return codes. > + * Note, negative errno values are possible for return values, too. > + * In case MSR emulation is called from an exit handler, any return value other > + * than KVM_MSR_RET_OK will normally result in a GP in the guest. > * > + * OK - Emulation succeeded. Must be 0, as in some cases return values > + * of functions returning 0 or -errno will just be passed on. > + * ERR - Some error occurred. > * UNSUPPORTED - The MSR isn't supported, either because it is completely > * unknown to KVM, or because the MSR should not exist according > * to the vCPU model. > * > * FILTERED - Access to the MSR is denied by a userspace MSR filter. > */ > +#define KVM_MSR_RET_OK 0 > +#define KVM_MSR_RET_ERR 1 > #define KVM_MSR_RET_UNSUPPORTED 2 > #define KVM_MSR_RET_FILTERED 3 I like the general idea of the series as 1/0 can indeed be confusing. What I'm wondering is if we can do better by changing 'int' return type to something else. I.e. if the result of the function can be 'passed on' and KVM_MSR_RET_OK/KVM_MSR_RET_ERR have one meaning while KVM_MSR_RET_UNSUPPORTED/KVM_MSR_RET_FILTERED have another, maybe we can do better by changing the return type to something and then, when the value needs to be passed on, do proper explicit vetting of the result (e.g. to make sure only 1/0 pass through)? Just a thought, I think the series as-is makes things better and we can go with it for now. -- Vitaly