From: Sean Christopherson <seanjc@google.com>
To: Zeng Guang <guang.zeng@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
Tony Luck <tony.luck@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Kim Phillips <kim.phillips@amd.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Jethro Beekman <jethro@fortanix.com>,
Kai Huang <kai.huang@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Robert Hu <robert.hu@intel.com>, Gao Chao <chao.gao@intel.com>
Subject: Re: [PATCH v2] kvm: selftests: Add KVM_CAP_MAX_VCPU_ID cap test
Date: Fri, 13 May 2022 01:03:23 +0000 [thread overview]
Message-ID: <Yn2uW0C+48fnDgfj@google.com> (raw)
In-Reply-To: <20220503064037.10822-1-guang.zeng@intel.com>
On Tue, May 03, 2022, Zeng Guang wrote:
> +int main(int argc, char *argv[])
> +{
> + struct kvm_vm *vm;
> + struct kvm_enable_cap cap = { 0 };
> + int ret;
> +
> + vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR);
> +
> + /* Get KVM_CAP_MAX_VCPU_ID cap supported in KVM */
> + ret = vm_check_cap(vm, KVM_CAP_MAX_VCPU_ID);
Because it's trivial to do so, and will avoid a hardcoded "max", what about looping
over all possible values? And then some arbitrary number of the max?
max_nr_vcpus = vm_check_cap(vm, KVM_CAP_MAX_VCPU_ID);
TEST_ASSERT(max_nr_vcpus > ???, ...)
for (i = 0; i < max_nr_vcpus; i++)
vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR);
vm_set_max_nr_vcpus(vm, 0);
vm_create_invalid_vcpu(vm, 0);
vm_set_max_nr_vcpus(vm, i);
vm_set_max_nr_vcpus(vm, i);
vm_create_invalid_vcpu(vm, i);
vm_create_invalid_vcpu(vm, i + 1);
vm_set_invalid_max_nr_vcpus(vm, 0);
vm_set_invalid_max_nr_vcpus(vm, i + 1);
vm_set_invalid_max_nr_vcpus(vm, i - 1);
vm_set_invalid_max_nr_vcpus(vm, max_nr_vcpus);
close(vm->fd);
}
for ( ; i < max_nr_vcpus + 100; i++) {
vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR);
vm_set_invalid_max_nr_vcpus(vm, i);
close(vm->fd);
}
> +
> + /* Check failure if set KVM_CAP_MAX_VCPU_ID beyond KVM cap */
> + cap.cap = KVM_CAP_MAX_VCPU_ID;
> + cap.args[0] = ret + 1;
> + ret = ioctl(vm->fd, KVM_ENABLE_CAP, &cap);
A helper or two to set the cap would be, uh, helpful :-) See above for ideas.
> + TEST_ASSERT(ret < 0,
> + "Unexpected success to enable KVM_CAP_MAX_VCPU_ID"
> + "beyond KVM cap!\n");
Please don't wrap quoted strings. Shorten the string and/or let the line run long.
For the string/message, prioritize information that the user _can't_ get from looking
at the code, and info that is highly relevant to the expectations. E.g. print the
the return value, the errno, and the allegedly bad value.
It's definitely helpful to provide context too (KVM Unit Tests drive me bonkers for
their terse messages), but for cases like this, it's redundant. "Unexpected success"
is redundant because the "ret < 0" conveys that failure was expected, and hopefully
most people will intuit that the test was trying "to enable" KVM_CAP_MAX_VCPU_ID.
If not, a quick glance at the code (file and line provided) will give them that info.
E.g. assuming this ends up in a helper, something like
TEST_ASSERT(ret == -1 && errno == EINVAL,
"KVM_CAP_MAX_VCPU_ID bug, max ID = %d, ret = %d, errno = %d (%s),
max_id, errno, strerror(errno));
IMO it's worth checking errno to reduce the probability of false pass, e.g. if the
ioctl() is rejected for some other reason due to a test bug.
> +
> + /* Check success if set KVM_CAP_MAX_VCPU_ID */
> + cap.args[0] = MAX_VCPU_ID;
> + ret = ioctl(vm->fd, KVM_ENABLE_CAP, &cap);
> + TEST_ASSERT(ret == 0,
> + "Unexpected failure to enable KVM_CAP_MAX_VCPU_ID!\n");
prev parent reply other threads:[~2022-05-13 1:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 6:40 [PATCH v2] kvm: selftests: Add KVM_CAP_MAX_VCPU_ID cap test Zeng Guang
2022-05-13 1:03 ` Sean Christopherson [this message]
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=Yn2uW0C+48fnDgfj@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=guang.zeng@intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=jethro@fortanix.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=robert.hu@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/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