Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp464752pxy; Wed, 28 Apr 2021 07:46:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2EDnRHLZ0OFIS33etexiN1ILGlr23TV0RAoVSlvXH4jrjLj0IYHekM8hn3SMJTYfXI4r1 X-Received: by 2002:a17:90a:6396:: with SMTP id f22mr4384207pjj.91.1619621203703; Wed, 28 Apr 2021 07:46:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619621203; cv=none; d=google.com; s=arc-20160816; b=Hb7Rd4r7kE8Mg1xRyvD6yE4BWyYsrhz03rHKXnpU/kmvfng/oXnbyxiuMF73pxvGMT lpb6hhca2Zv2Sge0sgZdgKJbcx+5Ttd5ee8FVb2QvLioBndjZQf1KNvofI3J68LIjKze eZX/y5k+Dcf2ugfTyyYSdfLLfOnZbV+YThwt1lSmaPGNJVLYQHZh7N/OQr85wUNZjge9 R66iIAgLEP0d36NacyFdChx9aj7sCMZUpzIiiphgalgwRCjbN1mKHUgpPEFXQQ/A7nKs vrlBDYIZRBhyk7eqhiOKBTWBX5Vl2K/+YY5vYGaOxqC9rQDOfKNDRqwMMKEH5d7gGtyu BnDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=Adfym8klH+5tYEalET56TZJSSzxtb4r5UMa5Cv/WfQY=; b=PFk+EZmR67h384cOObQdI7RdkFdDXzXSsbcv10vf+7TIsKUEttPQpO+gQVu3VzbFKT 5tK6ksLNfGGchkFNZIzxIICueQ2GxRb7cFU01zqi5RVQaT1hBQ0bTH3kjjDdsbw6RP5g 0VrClE2xjwa5oQNp6bB9VI4SuPjmz0mRCi0rZmX2GsW/6tFYoozMueu9kjCPRzsDsMgO gJNJtVvR+Z4CuOgc5XEV0Z2vtj4yeXkKZ0Ja/5FGk2S5ofPX/IFPe9u2/F9LhbOTEG1l pYgSy3EphZN2hH+4MDByXZSqq0A6mdF6A3ZV3E5RC1JfipOpPLgbZJJbjv/wNBLh9OhP oclQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IRuU2N15; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d11si4173852pfd.282.2021.04.28.07.46.18; Wed, 28 Apr 2021 07:46:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IRuU2N15; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237704AbhD1Mjr (ORCPT + 99 others); Wed, 28 Apr 2021 08:39:47 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:29867 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236857AbhD1Mjq (ORCPT ); Wed, 28 Apr 2021 08:39:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619613541; 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=Adfym8klH+5tYEalET56TZJSSzxtb4r5UMa5Cv/WfQY=; b=IRuU2N15QlXIcB7k3kkpPFdmVgcU8pTylDMGx4TzDQjFmel3v0UOY2HIiahVLnNXXyJ9k+ yoBAlsgUCqRSJzWryQxLqukzLyVR6KFwb12BPKllw98EZQXytLCYZpon58f3J3RgE6gBTf gMAeMBX2vaDPNmkdgIuVfdVJ2L+EzUU= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-588-z0KXcxQuOpi0zJYvZYVSsg-1; Wed, 28 Apr 2021 08:38:59 -0400 X-MC-Unique: z0KXcxQuOpi0zJYvZYVSsg-1 Received: by mail-ed1-f72.google.com with SMTP id v20-20020aa7cd540000b0290387928042f8so5859429edw.19 for ; Wed, 28 Apr 2021 05:38:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Adfym8klH+5tYEalET56TZJSSzxtb4r5UMa5Cv/WfQY=; b=Eqe2dedR1kE3uA/uwO7iQMS+i8eBdYhEESIGEzHLJLyi/4UWPlIOLmHlsK8YkkLAfs 7A5Fk8z/E54V90I2a41CBNbvWflR2igsUY8+6B3lfhTOLDys6UAnvTQgee6H6fROlJkR w0TVg4f7xA3qY3P/7bTVJ7bWpZt7Hy77YEbzzuVHQTEa/86LfelXlLB3n1EGFOyUZp7s n06lAqlIMJViZJD3LxBaelf27lAPtcgXjWG5B0czSKdFKb61XuhG463BJG7JaYypCsMR cfYTsypHSEtxtM+Oy/ayc2vnbCPesSXzEzvq2//J/cwqU07Jl6LPjsfw0wwX0zQ01sqf 01Xg== X-Gm-Message-State: AOAM531zl+aKbzCCgcZ3ZW95eAmIkUqByPx1C1ve0Vf3ZnKjnySFrxVP /2h5jouMUT4wDokYPYEIwfTIySUGEKd+qf/0Oq9FC9LLgWl3DqzJqrpEcKr5YH5IGqgzWXtaIhz VOjzF7hxeNomNNFaHzHVMhRIB X-Received: by 2002:a17:906:6a41:: with SMTP id n1mr29126509ejs.401.1619613538769; Wed, 28 Apr 2021 05:38:58 -0700 (PDT) X-Received: by 2002:a17:906:6a41:: with SMTP id n1mr29126479ejs.401.1619613538594; Wed, 28 Apr 2021 05:38:58 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id u1sm4785519edv.90.2021.04.28.05.38.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Apr 2021 05:38:58 -0700 (PDT) From: Vitaly Kuznetsov To: Valeriy Vdovin , linux-kernel@vger.kernel.org Cc: Denis Lunev , Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Shuah Khan , Aaron Lewis , Alexander Graf , Like Xu , Oliver Upton , Andrew Jones , kvm@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH] KVM: x86: Fix KVM_GET_CPUID2 ioctl to return cpuid entries count In-Reply-To: <20210428113655.26282-1-valeriy.vdovin@virtuozzo.com> References: <20210428113655.26282-1-valeriy.vdovin@virtuozzo.com> Date: Wed, 28 Apr 2021 14:38:57 +0200 Message-ID: <871raueg7y.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Valeriy Vdovin writes: > KVM_GET_CPUID2 kvm ioctl is not very well documented, but the way it is > implemented in function kvm_vcpu_ioctl_get_cpuid2 suggests that even at > error path it will try to return number of entries to the caller. But > The dispatcher kvm vcpu ioctl dispatcher code in kvm_arch_vcpu_ioctl > ignores any output from this function if it sees the error return code. > > It's very explicit by the code that it was designed to receive some > small number of entries to return E2BIG along with the corrected number. > > This lost logic in the dispatcher code has been restored by removing the > lines that check for function return code and skip if error is found. > Without it, the ioctl caller will see both the number of entries and the > correct error. > > In selftests relevant function vcpu_get_cpuid has also been modified to > utilize the number of cpuid entries returned along with errno E2BIG. > > Signed-off-by: Valeriy Vdovin > --- > arch/x86/kvm/x86.c | 10 +++++----- > .../selftests/kvm/lib/x86_64/processor.c | 20 +++++++++++-------- > 2 files changed, 17 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index efc7a82ab140..df8a3e44e722 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4773,14 +4773,14 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > r = -EFAULT; > if (copy_from_user(&cpuid, cpuid_arg, sizeof(cpuid))) > goto out; > + > r = kvm_vcpu_ioctl_get_cpuid2(vcpu, &cpuid, > cpuid_arg->entries); > - if (r) > - goto out; > - r = -EFAULT; > - if (copy_to_user(cpuid_arg, &cpuid, sizeof(cpuid))) It may make sense to check that 'r == -E2BIG' before trying to write anything back. I don't think it is correct/expected to modify nent in other cases (e.g. when kvm_vcpu_ioctl_get_cpuid2() returns -EFAULT) > + > + if (copy_to_user(cpuid_arg, &cpuid, sizeof(cpuid))) { > + r = -EFAULT; > goto out; > - r = 0; > + } > break; How is KVM userspace supposed to know if it can trust the 'nent' value (KVM is fixed case) or not (KVM is not fixed case)? This can probably be resolved with adding a new capability (but then I'm not sure the change is worth it to be honest). Also, if making such a change, API documentation in virt/kvm/api.rst needs updating. > } > case KVM_GET_MSRS: { > diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c > index a8906e60a108..a412b39ad791 100644 > --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c > +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c > @@ -727,17 +727,21 @@ struct kvm_cpuid2 *vcpu_get_cpuid(struct kvm_vm *vm, uint32_t vcpuid) > > cpuid = allocate_kvm_cpuid2(); > max_ent = cpuid->nent; > + cpuid->nent = 0; > > - for (cpuid->nent = 1; cpuid->nent <= max_ent; cpuid->nent++) { > - rc = ioctl(vcpu->fd, KVM_GET_CPUID2, cpuid); > - if (!rc) > - break; > + rc = ioctl(vcpu->fd, KVM_GET_CPUID2, cpuid); > + TEST_ASSERT(rc == -1 && errno == E2BIG, > + "KVM_GET_CPUID2 should return E2BIG: %d %d", > + rc, errno); > > - TEST_ASSERT(rc == -1 && errno == E2BIG, > - "KVM_GET_CPUID2 should either succeed or give E2BIG: %d %d", > - rc, errno); > - } > + TEST_ASSERT(cpuid->nent, > + "KVM_GET_CPUID2 failed to set cpuid->nent with E2BIG"); > + > + TEST_ASSERT(cpuid->nent < max_ent, > + "KVM_GET_CPUID2 has %d entries, expected maximum: %d", > + cpuid->nent, max_ent); > > + rc = ioctl(vcpu->fd, KVM_GET_CPUID2, cpuid); > TEST_ASSERT(rc == 0, "KVM_GET_CPUID2 failed, rc: %i errno: %i", > rc, errno); -- Vitaly