kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Janis Schoetterl-Glausch <scgl@linux.vnet.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Janis Schoetterl-Glausch <scgl@linux.ibm.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH v3 2/2] s390x: Test specification exceptions during transaction
Date: Tue, 26 Oct 2021 16:22:40 +0200	[thread overview]
Message-ID: <32dfb400-4191-44f8-354e-809fac890b63@linux.vnet.ibm.com> (raw)
In-Reply-To: <20211025193012.3be31938@p-imbrenda>

On 10/25/21 19:30, Claudio Imbrenda wrote:
> On Fri, 22 Oct 2021 14:01:56 +0200
> Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote:
> 
>> Program interruptions during transactional execution cause other
>> interruption codes.
>> Check that we see the expected code for (some) specification exceptions.
>>
>> Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
>> ---

[...]

>> +#define TRANSACTION_MAX_RETRIES 5
>> +
>> +/* NULL must be passed to __builtin_tbegin via constant, forbid diagnose from
>> + * being NULL to keep things simple
>> + */
>> +static int __attribute__((nonnull))
>> +with_transaction(void (*trigger)(void), struct __htm_tdb *diagnose)
>> +{
>> +	int cc;
>> +
> 
> if you want to be extra sure, put an assert here (although I'm not sure
> how nonnull works, I have never seen it before)

Ok, with nonnull, the compiler might warn you if you pass NULL.
> 
>> +	cc = __builtin_tbegin(diagnose);
>> +	if (cc == _HTM_TBEGIN_STARTED) {
>> +		trigger();
>> +		__builtin_tend();
>> +		return -TRANSACTION_COMPLETED;
>> +	} else {
>> +		return -cc;
>> +	}
>> +}
>> +
>> +static int retry_transaction(const struct spec_ex_trigger *trigger, unsigned int max_retries,
>> +			     struct __htm_tdb *tdb, uint16_t expected_pgm)
>> +{
>> +	int trans_result, i;
>> +	uint16_t pgm;
>> +
>> +	for (i = 0; i < max_retries; i++) {
>> +		expect_pgm_int();
>> +		trans_result = with_transaction(trigger->func, tdb);
>> +		if (trans_result == -_HTM_TBEGIN_TRANSIENT) {
>> +			mb();
>> +			pgm = lc->pgm_int_code;
>> +			if (pgm == 0)
>> +				continue;
>> +			else if (pgm == expected_pgm)
>> +				return 0;
>> +		}
>> +		return trans_result;
>> +	}
>> +	return -TRANSACTION_MAX_RETRIES;
> 
> so this means that a test will be considered failed if the transaction
> failed too many times?

Yes.
> 
> this means that could fail if the test is run on busy system, even if
> the host running the unit test is correct

I suppose so, don't know how likely that is.
> 
> also, do you really need to use negative values? it's probably easier
> to read if you stick to positive values, and less prone to mistakes if
> you accidentally forget a - somewhere.

Ok.
> 
>> +}
>> +
>> +static void test_spec_ex_trans(struct args *args, const struct spec_ex_trigger *trigger)
>> +{
>> +	const uint16_t expected_pgm = PGM_INT_CODE_SPECIFICATION
>> +			      | PGM_INT_CODE_TX_ABORTED_EVENT;
>> +	union {
>> +		struct __htm_tdb tdb;
>> +		uint64_t dwords[sizeof(struct __htm_tdb) / sizeof(uint64_t)];
>> +	} diag;
>> +	unsigned int i, failures = 0;
>> +	int trans_result;
>> +
>> +	if (!test_facility(73)) {
>> +		report_skip("transactional-execution facility not installed");
>> +		return;
>> +	}
>> +	ctl_set_bit(0, CTL0_TRANSACT_EX_CTL); /* enable transactional-exec */
>> +
>> +	for (i = 0; i < args->iterations && failures <= args->max_failures; i++) {
>> +		register_pgm_cleanup_func(trigger->fixup);
>> +		trans_result = retry_transaction(trigger, args->max_retries, &diag.tdb, expected_pgm);
> 
> so you retry each iteration up to args->max_retries times, and if a
> transaction aborts too many times (maybe because the host system is
> very busy), then you consider it a fail
> 

[...]

  parent reply	other threads:[~2021-10-26 14:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22 12:01 [kvm-unit-tests PATCH v3 0/2] Add specification exception tests Janis Schoetterl-Glausch
2021-10-22 12:01 ` [kvm-unit-tests PATCH v3 1/2] s390x: Add specification exception test Janis Schoetterl-Glausch
2021-10-25 17:17   ` Claudio Imbrenda
2021-10-26 12:00     ` Janis Schoetterl-Glausch
2021-10-26 13:41       ` Claudio Imbrenda
2021-10-27 10:00         ` Janis Schoetterl-Glausch
2021-10-27 12:08         ` Thomas Huth
2021-10-22 12:01 ` [kvm-unit-tests PATCH v3 2/2] s390x: Test specification exceptions during transaction Janis Schoetterl-Glausch
2021-10-25 17:30   ` Claudio Imbrenda
2021-10-25 18:28     ` Christian Borntraeger
2021-10-26 14:22     ` Janis Schoetterl-Glausch [this message]
2021-10-26 14:55       ` Claudio Imbrenda
2021-10-27 10:05         ` Janis Schoetterl-Glausch

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=32dfb400-4191-44f8-354e-809fac890b63@linux.vnet.ibm.com \
    --to=scgl@linux.vnet.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=scgl@linux.ibm.com \
    --cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).