All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Hildenbrand <david@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Janis Schoetterl-Glausch <scgl@linux.ibm.com>
Subject: Re: [PATCH 2/4] KVM: s390: selftests: Use TAP interface in the sync_regs test
Date: Thu, 14 Apr 2022 14:02:24 +0200	[thread overview]
Message-ID: <20d27b46-fe1f-4a80-0dba-e0ce5df934c9@redhat.com> (raw)
In-Reply-To: <20220414133950.20a84eef@p-imbrenda>

On 14/04/2022 13.39, Claudio Imbrenda wrote:
> On Thu, 14 Apr 2022 12:53:20 +0200
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> The sync_regs test currently does not have any output (unless one
>> of the TEST_ASSERT statement fails), so it's hard to say for a user
>> whether a certain new sub-test has been included in the binary or
>> not. Let's make this a little bit more user-friendly and include
>> some TAP output via the kselftests.h interface.
>> To be able to distinguish the different sub-tests more easily, we
>> also break up the huge main() function here in more fine grained
>> parts.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>   .../selftests/kvm/s390x/sync_regs_test.c      | 86 ++++++++++++++-----
>>   1 file changed, 65 insertions(+), 21 deletions(-)
>>
>> diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> index caf7b8859a94..d5ddcbb82d12 100644
>> --- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> +++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> @@ -21,6 +21,7 @@
>>   #include "test_util.h"
>>   #include "kvm_util.h"
>>   #include "diag318_test_handler.h"
>> +#include "kselftest.h"
>>   
>>   #define VCPU_ID 5
>>   
>> @@ -74,27 +75,9 @@ static void compare_sregs(struct kvm_sregs *left, struct kvm_sync_regs *right)
>>   #define TEST_SYNC_FIELDS   (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS|KVM_SYNC_DIAG318)
>>   #define INVALID_SYNC_FIELD 0x80000000
>>   
>> -int main(int argc, char *argv[])
>> +void test_read_invalid(struct kvm_vm *vm, struct kvm_run *run)
>>   {
>> -	struct kvm_vm *vm;
>> -	struct kvm_run *run;
>> -	struct kvm_regs regs;
>> -	struct kvm_sregs sregs;
>> -	int rv, cap;
>> -
>> -	/* Tell stdout not to buffer its content */
>> -	setbuf(stdout, NULL);
>> -
>> -	cap = kvm_check_cap(KVM_CAP_SYNC_REGS);
>> -	if (!cap) {
>> -		print_skip("CAP_SYNC_REGS not supported");
>> -		exit(KSFT_SKIP);
>> -	}
>> -
>> -	/* Create VM */
>> -	vm = vm_create_default(VCPU_ID, 0, guest_code);
>> -
>> -	run = vcpu_state(vm, VCPU_ID);
>> +	int rv;
>>   
>>   	/* Request reading invalid register set from VCPU. */
>>   	run->kvm_valid_regs = INVALID_SYNC_FIELD;
>> @@ -110,6 +93,11 @@ int main(int argc, char *argv[])
>>   		    "Invalid kvm_valid_regs did not cause expected KVM_RUN error: %d\n",
>>   		    rv);
>>   	vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
>> +}
>> +
>> +void test_set_invalid(struct kvm_vm *vm, struct kvm_run *run)
>> +{
>> +	int rv;
>>   
>>   	/* Request setting invalid register set into VCPU. */
>>   	run->kvm_dirty_regs = INVALID_SYNC_FIELD;
>> @@ -125,6 +113,13 @@ int main(int argc, char *argv[])
>>   		    "Invalid kvm_dirty_regs did not cause expected KVM_RUN error: %d\n",
>>   		    rv);
>>   	vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
>> +}
>> +
>> +void test_req_and_verify_all_valid_regs(struct kvm_vm *vm, struct kvm_run *run)
>> +{
>> +	struct kvm_sregs sregs;
>> +	struct kvm_regs regs;
>> +	int rv;
>>   
>>   	/* Request and verify all valid register sets. */
>>   	run->kvm_valid_regs = TEST_SYNC_FIELDS;
>> @@ -146,6 +141,13 @@ int main(int argc, char *argv[])
>>   
>>   	vcpu_sregs_get(vm, VCPU_ID, &sregs);
>>   	compare_sregs(&sregs, &run->s.regs);
>> +}
>> +
>> +void test_set_and_verify_various_reg_values(struct kvm_vm *vm, struct kvm_run *run)
>> +{
>> +	struct kvm_sregs sregs;
>> +	struct kvm_regs regs;
>> +	int rv;
>>   
>>   	/* Set and verify various register values */
>>   	run->s.regs.gprs[11] = 0xBAD1DEA;
>> @@ -180,6 +182,11 @@ int main(int argc, char *argv[])
>>   
>>   	vcpu_sregs_get(vm, VCPU_ID, &sregs);
>>   	compare_sregs(&sregs, &run->s.regs);
>> +}
>> +
>> +void test_clear_kvm_dirty_regs_bits(struct kvm_vm *vm, struct kvm_run *run)
>> +{
>> +	int rv;
>>   
>>   	/* Clear kvm_dirty_regs bits, verify new s.regs values are
>>   	 * overwritten with existing guest values.
>> @@ -200,8 +207,45 @@ int main(int argc, char *argv[])
>>   	TEST_ASSERT(run->s.regs.diag318 != 0x4B1D,
>>   		    "diag318 sync regs value incorrect 0x%llx.",
>>   		    run->s.regs.diag318);
>> +}
>> +
>> +struct testdef {
>> +	const char *name;
>> +	void (*test)(struct kvm_vm *vm, struct kvm_run *run);
>> +} testlist[] = {
>> +	{ "read invalid", test_read_invalid },
>> +	{ "set invalid", test_set_invalid },
>> +	{ "request+verify all valid regs", test_req_and_verify_all_valid_regs },
>> +	{ "set+verify various regs", test_set_and_verify_various_reg_values },
>> +	{ "clear kvm_dirty_regs bits", test_clear_kvm_dirty_regs_bits },
>> +};
>> +
>> +int main(int argc, char *argv[])
>> +{
>> +	static struct kvm_run *run;
>> +	static struct kvm_vm *vm;
>> +	int idx;
>> +
>> +	/* Tell stdout not to buffer its content */
>> +	setbuf(stdout, NULL);
>> +
>> +	if (!kvm_check_cap(KVM_CAP_SYNC_REGS))
>> +		ksft_exit_skip("CAP_SYNC_REGS not supported");
> 
> I'm not an expert on the TAP format, but wouldn't it be more meaningful
> to print the header first? (like you do in the previous patch)

It shouldn't matter much, without the header, TAP version 12 will be used:

  https://testanything.org/tap-specification.html

With header, it switches to version 13:

  https://testanything.org/tap-version-13-specification.html

But the "1..0" lines (which signal a complete skip) are part of both 
versions, so we should be fine here.

(but I can also move it in case I have to respin anyway)

  Thomas


  reply	other threads:[~2022-04-14 12:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 10:53 [PATCH 0/4] KVM: s390: selftests: Provide TAP output in tests Thomas Huth
2022-04-14 10:53 ` [PATCH 1/4] KVM: s390: selftests: Use TAP interface in the memop test Thomas Huth
2022-04-14 12:48   ` Janis Schoetterl-Glausch
2022-04-19 17:40     ` Thomas Huth
2022-04-20 10:55       ` Janis Schoetterl-Glausch
2022-04-14 10:53 ` [PATCH 2/4] KVM: s390: selftests: Use TAP interface in the sync_regs test Thomas Huth
2022-04-14 11:39   ` Claudio Imbrenda
2022-04-14 12:02     ` Thomas Huth [this message]
2022-04-14 10:53 ` [PATCH 3/4] KVM: s390: selftests: Use TAP interface in the tprot test Thomas Huth
2022-04-14 11:51   ` Claudio Imbrenda
2022-04-14 12:08     ` Thomas Huth
2022-04-14 12:33       ` Janis Schoetterl-Glausch
2022-04-19 17:45         ` Thomas Huth
2022-04-14 10:53 ` [PATCH 4/4] KVM: s390: selftests: Use TAP interface in the reset test Thomas Huth

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=20d27b46-fe1f-4a80-0dba-e0ce5df934c9@redhat.com \
    --to=thuth@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=scgl@linux.ibm.com \
    --cc=shuah@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.