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
>
[...]
next prev 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).