Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4479261ybb; Tue, 14 Apr 2020 08:06:47 -0700 (PDT) X-Google-Smtp-Source: APiQypKCKsK8AqcquB56J1l339n8jqhNuBJ4NMUTHzgXvp58lOqdqMTc2CxI8N2qhmdusN6Hs48C X-Received: by 2002:a17:906:970e:: with SMTP id k14mr565074ejx.202.1586876806817; Tue, 14 Apr 2020 08:06:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586876806; cv=none; d=google.com; s=arc-20160816; b=X9DmgSVkrCCJPyu4QMenQH184BSbXlJ2bZXERbzFea01jdHbR2HF1wDJvjfGZUgtMn 7R4I6ZSGNTIVEYaELq5fGeXd9mEbOhbMMuOf1jxjnwtAp3v1eaXInjPoCGyC2PUmR0U/ gGbB9oXw4R5NbRMuVTll1Bwtws32T+x2wRZu6fyKy5oB30g40Kp3tQjNCR9B0tBtEua2 Z3hQyp0etlHXGyoAKfJk2F4s2M95Djecgfveo3SbIWhCqD/Jqh0+eW61qKvugpAVKzqd fXFc+hvbQ9Ttc2ELryCvXfTcL8cVeiAtT5MtJn9XlV/TWJUCxDXhQTK6Ev1ojYDXtaYV jAxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=7XKy2uSMzlsVUHR3bvdi0/jwn8IqYuRkSqt7prdnHg0=; b=doxaRZE1ObiJsX2KWHlGYYax3k5x8CWOAAneJ6O13FYV43kr7Zd8XSp+s8o+Ms/IJH ixqv6VdY+YoUCgjXU821P7LDPQkMbrv1rTWlDBzG15gnCLYQrKQq60zRm0VmlvM6qhAT 3alrgpzinnDkFVhm2qWA7aPFts7H65IevT3VlEPcH/QgHJ16C6zzggtFZ1n1kySj7A4f KFEvWPFWen/oppL+Z6E7pQy7pHBmVT2OH8bV9qbrjG5sPWhSH9l5W/zRNGB74vGMe8gu bBzWVY+LVfgaNP2F98cX5ga71jGwGA1s3Y+1RBu7RwHzor4YvSqEVSscjUi1EkyfiFNA Pm6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OXslx5M1; spf=pass (google.com: best guess record for 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 f11si5767924ejb.492.2020.04.14.08.06.19; Tue, 14 Apr 2020 08:06:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for 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=OXslx5M1; spf=pass (google.com: best guess record for 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 S2436753AbgDNI03 (ORCPT + 99 others); Tue, 14 Apr 2020 04:26:29 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:33807 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2436767AbgDNI0Q (ORCPT ); Tue, 14 Apr 2020 04:26:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586852774; 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=7XKy2uSMzlsVUHR3bvdi0/jwn8IqYuRkSqt7prdnHg0=; b=OXslx5M1XGasPhUmOa4wSo9tWds0QXjTeyaYbaoEmL/qPlzvWVF4ExlDgyfcszXA+9mvrx dhioFrKyzShGEx0m36tA573/d2nzKwB4Gsvq/yfjJltqdFrzkLQarX28Hq3DeO4Vj5MFHv 4hfRhKaaLd84vCgnBIktxnpIwnXOOzw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-68-DgTxY84wMJib1-rqSYAARQ-1; Tue, 14 Apr 2020 04:26:12 -0400 X-MC-Unique: DgTxY84wMJib1-rqSYAARQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A7C94107ACCD; Tue, 14 Apr 2020 08:26:11 +0000 (UTC) Received: from kamzik.brq.redhat.com (unknown [10.40.195.188]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A0D9510013A1; Tue, 14 Apr 2020 08:25:59 +0000 (UTC) Date: Tue, 14 Apr 2020 10:25:56 +0200 From: Andrew Jones To: Sean Christopherson Cc: Wainer dos Santos Moschetta , Paolo Bonzini , Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Xu Subject: Re: [PATCH 01/10] KVM: selftests: Take vcpu pointer instead of id in vm_vcpu_rm() Message-ID: <20200414082556.nfdgec63kuqknpxc@kamzik.brq.redhat.com> References: <20200410231707.7128-1-sean.j.christopherson@intel.com> <20200410231707.7128-2-sean.j.christopherson@intel.com> <20200413212659.GB21204@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200413212659.GB21204@linux.intel.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 13, 2020 at 02:26:59PM -0700, Sean Christopherson wrote: > On Mon, Apr 13, 2020 at 03:26:55PM -0300, Wainer dos Santos Moschetta wrote: > > > > On 4/10/20 8:16 PM, Sean Christopherson wrote: > > >The sole caller of vm_vcpu_rm() already has the vcpu pointer, take it > > >directly instead of doing an extra lookup. > > > > > > Most of (if not all) vcpu related functions in kvm_util.c receives an id, so > > this change creates an inconsistency. > > Ya, but taking the id is done out of "necessity", as everything is public > and for whatever reason the design of the selftest framework is to not > expose 'struct vcpu' outside of the utils. vm_vcpu_rm() is internal only, > IMO pulling the id out of the vcpu just to lookup the same vcpu is a waste > of time. Agreed > > FWIW, I think the whole vcpuid thing is a bad interface, almost all the > tests end up defining an arbitrary number for the sole VCPU_ID, i.e. the > vcpuid interface just adds a pointless layer of obfuscation. I haven't > looked through all the tests, but returning the vcpu and making the struct > opaque, same as kvm_vm, seems like it would yield more readable code with > less overhead. Agreed > > While I'm on a soapbox, hiding 'struct vcpu' and 'struct kvm_vm' also seems > rather silly, but at least that doesn't directly lead to funky code. Agreed. While the concept has been slowly growing on me, I think accessor functions for each of the structs members are growing even faster... Thanks, drew > > > Disregarding the above comment, the changes look good to me. So: > > > > Reviewed-by: Wainer dos Santos Moschetta > > > > > > > > > >Signed-off-by: Sean Christopherson > > >--- > > > tools/testing/selftests/kvm/lib/kvm_util.c | 7 +++---- > > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > > >diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c > > >index 8a3523d4434f..9a783c20dd26 100644 > > >--- a/tools/testing/selftests/kvm/lib/kvm_util.c > > >+++ b/tools/testing/selftests/kvm/lib/kvm_util.c > > >@@ -393,7 +393,7 @@ struct vcpu *vcpu_find(struct kvm_vm *vm, uint32_t vcpuid) > > > * > > > * Input Args: > > > * vm - Virtual Machine > > >- * vcpuid - VCPU ID > > >+ * vcpu - VCPU to remove > > > * > > > * Output Args: None > > > * > > >@@ -401,9 +401,8 @@ struct vcpu *vcpu_find(struct kvm_vm *vm, uint32_t vcpuid) > > > * > > > * Within the VM specified by vm, removes the VCPU given by vcpuid. > > > */ > > >-static void vm_vcpu_rm(struct kvm_vm *vm, uint32_t vcpuid) > > >+static void vm_vcpu_rm(struct kvm_vm *vm, struct vcpu *vcpu) > > > { > > >- struct vcpu *vcpu = vcpu_find(vm, vcpuid); > > > int ret; > > > ret = munmap(vcpu->state, sizeof(*vcpu->state)); > > >@@ -427,7 +426,7 @@ void kvm_vm_release(struct kvm_vm *vmp) > > > int ret; > > > while (vmp->vcpu_head) > > >- vm_vcpu_rm(vmp, vmp->vcpu_head->id); > > >+ vm_vcpu_rm(vmp, vmp->vcpu_head); > > > ret = close(vmp->fd); > > > TEST_ASSERT(ret == 0, "Close of vm fd failed,\n" > > >