public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Nico Boehr <nrb@linux.ibm.com>,
	kvm@vger.kernel.org, frankja@linux.ibm.com, thuth@redhat.com
Subject: Re: [kvm-unit-tests PATCH v2 1/1] s390x: add parallel skey migration test
Date: Tue, 13 Dec 2022 14:49:10 +0100	[thread overview]
Message-ID: <e1cea42fbfc22b6fc99b96e9c48a761eb14253bd.camel@linux.ibm.com> (raw)
In-Reply-To: <20221213131416.68e0cada@p-imbrenda>

On Tue, 2022-12-13 at 13:14 +0100, Claudio Imbrenda wrote:
> On Tue, 13 Dec 2022 12:11:29 +0100
> Nina Schoetterl-Glausch <nsg@linux.ibm.com> wrote:
> 
> > On Tue, 2022-12-13 at 09:50 +0100, Nico Boehr wrote:
> > > Quoting Nina Schoetterl-Glausch (2022-12-12 21:37:28)  
> > > > On Fri, 2022-12-09 at 11:21 +0100, Nico Boehr wrote:  
> > > > > Right now, we have a test which sets storage keys, then migrates the VM
> > > > > and - after migration finished - verifies the skeys are still there.
> > > > > 
> > > > > Add a new version of the test which changes storage keys while the
> > > > > migration is in progress. This is achieved by adding a command line
> > > > > argument to the existing migration-skey test.
> > > > > 
> > > > > Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
> > > > > ---
> > > > >  s390x/migration-skey.c | 214 +++++++++++++++++++++++++++++++++++------
> > > > >  s390x/unittests.cfg    |  15 ++-
> > > > >  2 files changed, 198 insertions(+), 31 deletions(-)
> > > > > 
> > > > > diff --git a/s390x/migration-skey.c b/s390x/migration-skey.c
> > > > > index b7bd82581abe..9b9a45f4ad3b 100644
> > > > > --- a/s390x/migration-skey.c
> > > > > +++ b/s390x/migration-skey.c
> > > > >   
> > > > [...]
> > > >   
> > > > > +static void test_skey_migration_parallel(void)
> > > > > +{
> > > > > +     report_prefix_push("parallel");
> > > > > +
> > > > > +     if (smp_query_num_cpus() == 1) {
> > > > > +             report_skip("need at least 2 cpus for this test");
> > > > > +             goto error;
> > > > > +     }
> > > > > +
> > > > > +     smp_cpu_setup(1, PSW_WITH_CUR_MASK(set_skeys_thread));
> > > > > +
> > > > > +     migrate_once();
> > > > > +
> > > > > +     WRITE_ONCE(thread_should_exit, 1);
> > > > > +
> > > > > +     while (!thread_exited)
> > > > > +             mb();  
> > > > 
> > > > Are you doing it this way instead of while(!READ_ONCE(thread_exited)); so the mb() does double duty
> > > > and ensures "result" is also read from memory a couple of lines down?  
> > > 
> > > It is a good point, actually I just did what we already do in wait_for_flag in s390x/smp.c. :-)
> > >   
> > > > If so, I wonder if the compiler is allowed to arrange the control flow such that if the loop condition
> > > > is false on the first iteration it uses a cached value of "result" (I'd be guessing yes, but what do I know).  
> > > 
> > > I agree, but it does not matter, does it? At latest the second iteration will actually read from memory, no?  
> > 
> > Well, if the condition is false on the first iteration, there won't be a second one.
> > >   
> > > > In any case using a do while loop instead would eliminate the question.
> > > > A comment might be nice, too.  
> > > 
> > > How about I change to
> > >   while(!READ_ONCE(thread_exited)); 
> > > and add an explicit mb() below to ensure result is read from memory?  
> > 
> > Fine by me. Could also use READ_ONCE for result. You decide.
> > Btw, doesn't checkpatch complain about mb() without comment?
> 
> there is no checkpatch for kvm unit tests :)

Well, ok, depends what you consider part of the coding style then :)
Since k-u-t uses kernel style. I run it and then ignore what I judge reasonable to ignore :)
> 
> > Although I think I've ignored that before, too.
> > 
> 


  reply	other threads:[~2022-12-13 13:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09 10:21 [kvm-unit-tests PATCH v2 0/1] s390x: test storage keys during migration Nico Boehr
2022-12-09 10:21 ` [kvm-unit-tests PATCH v2 1/1] s390x: add parallel skey migration test Nico Boehr
2022-12-12 20:37   ` Nina Schoetterl-Glausch
2022-12-13  8:50     ` Nico Boehr
2022-12-13 11:11       ` Nina Schoetterl-Glausch
2022-12-13 12:14         ` Claudio Imbrenda
2022-12-13 13:49           ` Nina Schoetterl-Glausch [this message]
2022-12-14 10:17         ` Nico Boehr
2022-12-13 17:00       ` Claudio Imbrenda
2022-12-13 17:27   ` Claudio Imbrenda
2022-12-14 12:18     ` Nico Boehr

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=e1cea42fbfc22b6fc99b96e9c48a761eb14253bd.camel@linux.ibm.com \
    --to=nsg@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=nrb@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