From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
To: Laurent Vivier <lvivier@redhat.com>, kvm@vger.kernel.org
Cc: thuth@redhat.com, kvm-ppc@vger.kernel.org, dgibson@redhat.com
Subject: Re: [kvm-unit-tests PATCH] powerpc: Allow for a custom decr value to be specified to load on decr excp
Date: Fri, 03 May 2019 08:55:14 +1000 [thread overview]
Message-ID: <1556837714.1887.3.camel@gmail.com> (raw)
In-Reply-To: <ec8d1a58-e066-f61a-ad28-92b82fccdbff@redhat.com>
On Thu, 2019-05-02 at 10:01 +0200, Laurent Vivier wrote:
> On 01/05/2019 09:00, Suraj Jitindar Singh wrote:
> > 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>
> > ---
> > lib/powerpc/handlers.c | 7 ++++---
> > powerpc/sprs.c | 3 ++-
> > powerpc/tm.c | 3 ++-
> > 3 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/powerpc/handlers.c b/lib/powerpc/handlers.c
> > index be8226a..c8721e0 100644
> > --- a/lib/powerpc/handlers.c
> > +++ b/lib/powerpc/handlers.c
> > @@ -12,11 +12,12 @@
> >
> > /*
> > * Generic handler for decrementer exceptions (0x900)
> > - * Just reset the decrementer back to its maximum value
> > (0x7FFFFFFF)
> > + * Just reset the decrementer back to the value specified when
> > registering the
> > + * handler
> > */
> > -void dec_except_handler(struct pt_regs *regs __unused, void *data
> > __unused)
> > +void dec_except_handler(struct pt_regs *regs __unused, void *data)
> > {
> > - uint32_t dec = 0x7FFFFFFF;
> > + uint64_t dec = *((uint64_t *) data);
> >
> > asm volatile ("mtdec %0" : : "r" (dec));
> > }
> > diff --git a/powerpc/sprs.c b/powerpc/sprs.c
> > index 6744bd8..3bd6ac7 100644
> > --- a/powerpc/sprs.c
> > +++ b/powerpc/sprs.c
> > @@ -253,6 +253,7 @@ int main(int argc, char **argv)
> > 0x1234567890ABCDEFULL, 0xFEDCBA0987654321ULL,
> > -1ULL,
> > };
> > + uint64_t decr = 0x7FFFFFFF;
> >
> > 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);
> > }
> > diff --git a/powerpc/tm.c b/powerpc/tm.c
> > index bd56baa..0f3f543 100644
> > --- a/powerpc/tm.c
> > +++ b/powerpc/tm.c
> > @@ -95,11 +95,12 @@ static bool enable_tm(void)
> > static void test_h_cede_tm(int argc, char **argv)
> > {
> > int i;
> > + uint64_t decr = 0x3FFFFF;
> >
> > if (argc > 2)
> > report_abort("Unsupported argument: '%s'",
> > argv[2]);
> >
> > - handle_exception(0x900, &dec_except_handler, NULL);
> > + handle_exception(0x900, &dec_except_handler, &decr);
>
> Maybe you should also need here:
>
> asm volatile ("mtdec %0" : : "r" (decr));
>
> To set the first one to the same values as the following ones?
I guess we could get a case where the decrementer is really large (if
large decrementer is enabled for example) and otherwise we just don't
wake up...
In practise I'm not sure. But I'll add it if you like
Suraj.
>
> Thanks,
> Laurent
next prev parent reply other threads:[~2019-05-02 22:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 7:00 [kvm-unit-tests PATCH] powerpc: Allow for a custom decr value to be specified to load on decr excp Suraj Jitindar Singh
2019-05-02 8:01 ` Laurent Vivier
2019-05-02 22:55 ` Suraj Jitindar Singh [this message]
2019-05-03 5:49 ` Thomas Huth
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=1556837714.1887.3.camel@gmail.com \
--to=sjitindarsingh@gmail.com \
--cc=dgibson@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=lvivier@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