All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org, Janosch Frank <frankja@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Sebastian Mitterle <smitterl@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	linux-s390@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH v2 2/2] s390x: firq: floating interrupt test
Date: Mon, 6 Dec 2021 09:15:00 +0100	[thread overview]
Message-ID: <959de529-503e-6dbf-b4ea-67e13252a86a@redhat.com> (raw)
In-Reply-To: <babd1100-844b-e00c-3e5b-30f7bca65636@redhat.com>

>>>
>>>>
>>>>> +
>>>>> +	/*
>>>>> +	 * We want CPU #2 to be stopped. This should be the case at this
>>>>> +	 * point, however, we want to sense if it even exists as well.
>>>>> +	 */
>>>>> +	ret = smp_cpu_stop(2);
>>>>> +	if (ret) {
>>>>> +		report_skip("CPU #2 not found");
>>>>
>>>> Since you already queried for the availablity of at least 3 CPUs above, I
>>>> think you could turn this into a report_fail() instead?
>>>
>>> either that or an assert, but again, no strong opinions
>>>
>>
>> Just because there are >= 3 CPUs doesn't imply that CPU #2 is around.
> 
> Ok, fair point. But if #2 is not around, it means that the test has been run 
> in the wrong way by the user... I wonder what's better in that case - to 
> skip this test or to go out with a bang. Skipping the test has the advantage 
> of looking a little bit more "polite", but it has the disadvantage that it 
> might get lost in automation, e.g. if somebody enabled the test in their CI, 
> but did something wrong in the settings, they might not notice that the test 
> is not run at all...

I sticked to what we have in s390x/smp.c, where we fail if we only have
a single CPU.

But I don't particularly care (and have to move on doing other stuff),
so I'll do whatever maintainers want and resend :)

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-12-06  8:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-02 12:35 [kvm-unit-tests PATCH v2 0/2] s390x: firq: floating interrupt test David Hildenbrand
2021-12-02 12:35 ` [kvm-unit-tests PATCH v2 1/2] s390x: make smp_cpu_setup() return 0 on success David Hildenbrand
2021-12-02 12:35 ` [kvm-unit-tests PATCH v2 2/2] s390x: firq: floating interrupt test David Hildenbrand
2021-12-02 12:45   ` Claudio Imbrenda
2021-12-03 10:55   ` Thomas Huth
2021-12-03 11:18     ` Claudio Imbrenda
2021-12-03 11:22       ` Thomas Huth
2021-12-03 18:23       ` David Hildenbrand
2021-12-06  7:12         ` Thomas Huth
2021-12-06  8:15           ` David Hildenbrand [this message]
2021-12-06 11:09             ` Claudio Imbrenda
2021-12-06 13:35 ` [kvm-unit-tests PATCH v2 0/2] " Claudio Imbrenda

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=959de529-503e-6dbf-b4ea-67e13252a86a@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.ibm.com \
    --cc=smitterl@redhat.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 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.