public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
To: "Thomas Huth" <thuth@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	kvm@vger.kernel.org
Cc: kvm-ppc@vger.kernel.org
Subject: Re: [kvm-unit-tests PULL 1/2] powerpc: Allow for a custom decr value to be specified to load on decr excp
Date: Mon, 20 May 2019 14:47:27 +1000	[thread overview]
Message-ID: <1558327647.5110.0.camel@gmail.com> (raw)
In-Reply-To: <1bea83ba-6c64-3b21-baca-8c414ea86770@redhat.com>

On Fri, 2019-05-17 at 15:10 +0200, Thomas Huth wrote:
> On 17/05/2019 15.03, Laurent Vivier wrote:
> > From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> > 
> > Currently the handler for a decrementer exception will simply
> > reload the
> > maximum value (0x7FFFFFFF), which will take ~4 seconds to expire
> > again.
> > This means that if a vcpu cedes, it will be ~4 seconds between
> > wakeups.
> > 
> > The h_cede_tm test is testing a known breakage when a guest cedes
> > while
> > suspended. To be sure we cede 500 times to check for the bug.
> > However
> > since it takes ~4 seconds to be woken up once we've ceded, we only
> > get
> > through ~20 iterations before we reach the 90 seconds timeout and
> > the
> > test appears to fail.
> > 
> > Add an option when registering the decrementer handler to specify
> > the
> > value which should be reloaded by the handler, allowing the timeout
> > to be
> > chosen.
> > 
> > Modify the spr test to use the max timeout to preserve existing
> > behaviour.
> > Modify the h_cede_tm test to use a 10ms timeout to ensure we can
> > perform
> > 500 iterations before hitting the 90 second time limit for a test.
> > 
> > This means the h_cede_tm test now succeeds rather than timing out.
> > 
> > Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> > Reviewed-by: Thomas Huth <thuth@redhat.com>
> > Reviewed-by: Laurent Vivier <lvivier@redhat.com>
> > [lv: reset initial value to 0x3FFFFFFF]
> 
> Looks like something went wrong here? There is still the 0x7FFFFFFF
> in
> the hunk below...

No, I think this is correct.
Max value is ox7FFFFFFF, but the initial value we load via mtdec is the
original 0x3FFFFFFF.

> 
> > diff --git a/powerpc/sprs.c b/powerpc/sprs.c
> > index 6744bd8d8049..3c2d98c9ca99 100644
> > --- a/powerpc/sprs.c
> > +++ b/powerpc/sprs.c
> > @@ -253,6 +253,7 @@ int main(int argc, char **argv)
> >  		0x1234567890ABCDEFULL, 0xFEDCBA0987654321ULL,
> >  		-1ULL,
> >  	};
> > +	static uint64_t decr = 0x7FFFFFFF; /* Max value */
> >  
> >  	for (i = 1; i < argc; i++) {
> >  		if (!strcmp(argv[i], "-w")) {
> > @@ -288,7 +289,7 @@ int main(int argc, char **argv)
> >  		(void) getchar();
> >  	} else {
> >  		puts("Sleeping...\n");
> > -		handle_exception(0x900, &dec_except_handler,
> > NULL);
> > +		handle_exception(0x900, &dec_except_handler,
> > &decr);
> >  		asm volatile ("mtdec %0" : : "r" (0x3FFFFFFF));
> >  		hcall(H_CEDE);
> >  	}
> 
>  Thomas

  reply	other threads:[~2019-05-20  4:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-17 13:03 [kvm-unit-tests PULL 0/2] Ppc next patches Laurent Vivier
2019-05-17 13:03 ` [kvm-unit-tests PULL 1/2] powerpc: Allow for a custom decr value to be specified to load on decr excp Laurent Vivier
2019-05-17 13:10   ` Thomas Huth
2019-05-20  4:47     ` Suraj Jitindar Singh [this message]
2019-05-20  6:12       ` Laurent Vivier
2019-05-20  7:03         ` Thomas Huth
2019-05-17 13:03 ` [kvm-unit-tests PULL 2/2] powerpc: Make h_cede_tm test run by default Laurent Vivier
2019-06-03  8:24 ` [kvm-unit-tests PULL 0/2] Ppc next patches Laurent Vivier
2019-06-06 12:27   ` Paolo Bonzini
2019-06-06 12:08 ` Paolo Bonzini

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=1558327647.5110.0.camel@gmail.com \
    --to=sjitindarsingh@gmail.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox