All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janosch Frank <frankja@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, david@redhat.com
Subject: Re: [kvm-unit-tests PATCH] s390x: Workaround smp stop and store status race
Date: Tue, 9 Feb 2021 17:42:40 +0100	[thread overview]
Message-ID: <c87888b4-9ced-9255-e7e7-cb05219c9c21@linux.ibm.com> (raw)
In-Reply-To: <f0aa4cc7-03dd-5761-8cc5-ceeb834526f8@redhat.com>

On 2/9/21 5:19 PM, Thomas Huth wrote:
> On 09/02/2021 17.14, Janosch Frank wrote:
>> On 2/9/21 5:08 PM, Claudio Imbrenda wrote:
>>> On Tue,  9 Feb 2021 09:15:54 -0500
>>> Janosch Frank <frankja@linux.ibm.com> wrote:
>>>
>>>> KVM and QEMU handle a SIGP stop and store status in two steps:
>>>> 1) Stop the CPU by injecting a stop request
>>>> 2) Store when the CPU has left SIE because of the stop request
>>>>
>>>> The problem is that the SIGP order is already considered completed by
>>>> KVM/QEMU when step 1 has been performed and not once both have
>>>> completed. In addition we currently don't implement the busy CC so a
>>>> kernel has no way of knowing that the store has finished other than
>>>> checking the location for the store.
>>>>
>>>> This workaround is based on the fact that for a new SIE entry (via the
>>>> added smp restart) a stop with the store status has to be finished
>>>> first.
>>>>
>>>> Correct handling of this in KVM/QEMU will need some thought and time.
>>>
>>> do I understand correctly that you are here "fixing" the test by not
>>> triggering the KVM bug? Shouldn't we try to trigger as many bugs as
>>> possible instead?
>>
>> This is not a bug, it's missing code :-)
>>
>> We trigger a higher number of bugs by running tests and this workaround
>> does exactly that by letting Thomas use the smp test in the CI again.
> 
> Alternatively, we could use report_xfail here to make the test pass, but 
> still have the problem reported so that we do not forget to fix it later.
> 
>   Thomas
> 

I have no strong opinion on that although I'll need to have a look if
our CI flags XPASS/XFAIL as fails.

  reply	other threads:[~2021-02-09 16:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 14:15 [kvm-unit-tests PATCH] s390x: Workaround smp stop and store status race Janosch Frank
2021-02-09 14:21 ` Thomas Huth
2021-02-09 16:08 ` Claudio Imbrenda
2021-02-09 16:14   ` Janosch Frank
2021-02-09 16:19     ` Thomas Huth
2021-02-09 16:42       ` Janosch Frank [this message]
2021-02-09 16:55 ` David Hildenbrand

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=c87888b4-9ced-9255-e7e7-cb05219c9c21@linux.ibm.com \
    --to=frankja@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --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.