mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Wainer dos Santos Moschetta <wainersm@redhat.com>
To: Andrew Jones <drjones@redhat.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH 01/10] KVM: selftests: Take vcpu pointer instead of id in vm_vcpu_rm()
Date: Tue, 14 Apr 2020 10:02:08 -0300	[thread overview]
Message-ID: <023b0cb2-50d7-9145-d065-32436d429806@redhat.com> (raw)
In-Reply-To: <20200414082556.nfdgec63kuqknpxc@kamzik.brq.redhat.com>


On 4/14/20 5:25 AM, Andrew Jones wrote:
> 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


Thanks Sean and Andrew for your comments. I'm not in position to 
change/propose any design of kvm selftests but even though I aimed to 
foster this discussion.

So, please, consider my Reviewed-by...

- Wainer


>
>> 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 <wainersm@redhat.com>
>>>
>>>
>>>> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
>>>> ---
>>>>   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"


  reply	other threads:[~2020-04-14 13:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-10 23:16 [PATCH 00/10] KVM: selftests: Add KVM_SET_MEMORY_REGION tests Sean Christopherson
2020-04-10 23:16 ` [PATCH 01/10] KVM: selftests: Take vcpu pointer instead of id in vm_vcpu_rm() Sean Christopherson
2020-04-13 18:26   ` Wainer dos Santos Moschetta
2020-04-13 21:26     ` Sean Christopherson
2020-04-14  8:25       ` Andrew Jones
2020-04-14 13:02         ` Wainer dos Santos Moschetta [this message]
2020-04-15 15:11       ` Paolo Bonzini
2020-04-14 16:02   ` Andrew Jones
2020-04-10 23:16 ` [PATCH 02/10] KVM: selftests: Use kernel's list instead of homebrewed replacement Sean Christopherson
2020-04-14 16:03   ` Andrew Jones
2020-04-10 23:17 ` [PATCH 03/10] KVM: selftests: Add util to delete memory region Sean Christopherson
2020-04-13 18:52   ` Wainer dos Santos Moschetta
2020-04-14 16:04   ` Andrew Jones
2020-04-10 23:17 ` [PATCH 04/10] KVM: selftests: Add GUEST_ASSERT variants to pass values to host Sean Christopherson
2020-04-14 16:02   ` Andrew Jones
2020-04-10 23:17 ` [PATCH 05/10] KVM: sefltests: Add explicit synchronization to move mem region test Sean Christopherson
2020-04-10 23:17 ` [PATCH 06/10] KVM: selftests: Add "delete" testcase to set_memory_region_test Sean Christopherson
2020-04-14 16:19   ` Andrew Jones
2020-04-14 16:29     ` Andrew Jones
2020-04-10 23:17 ` [PATCH 07/10] selftests: kvm: Add vm_get_fd() in kvm_util Sean Christopherson
2020-04-10 23:17 ` [PATCH 08/10] KVM: selftests: Add "zero" testcase to set_memory_region_test Sean Christopherson
2020-04-10 23:17 ` [PATCH 09/10] KVM: selftests: Make set_memory_region_test common to all architectures Sean Christopherson
2020-04-14 14:43   ` Wainer dos Santos Moschetta
2020-04-10 23:17 ` [PATCH 10/10] selftests: kvm: Add testcase for creating max number of memslots Sean Christopherson
2020-04-13 13:22   ` Wainer dos Santos Moschetta
2020-04-15 15:40 ` [PATCH 00/10] KVM: selftests: Add KVM_SET_MEMORY_REGION tests Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=023b0cb2-50d7-9145-d065-32436d429806@redhat.com \
    --to=wainersm@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=drjones@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®