From: Andrew Jones <drjones@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: mttcg@greensocs.com, "Peter Maydell" <peter.maydell@linaro.org>,
"Alexander Spyridakis" <a.spyridakis@virtualopensystems.com>,
"Mark Burton" <mark.burton@greensocs.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"KONRAD Frédéric" <fred.konrad@greensocs.com>
Subject: Re: [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (MTTCG)
Date: Fri, 26 Jun 2015 10:05:38 +0200 [thread overview]
Message-ID: <20150626080538.GD3682@hawk.localdomain> (raw)
In-Reply-To: <878ub7aqy8.fsf@linaro.org>
On Fri, Jun 26, 2015 at 08:06:55AM +0100, Alex Bennée wrote:
>
> Andrew Jones <drjones@redhat.com> writes:
>
> > On Wed, Jun 24, 2015 at 08:12:52PM +0100, Peter Maydell wrote:
> >> On 24 June 2015 at 18:18, Alex Bennée <alex.bennee@linaro.org> wrote:
> >> >
> >> > Paolo Bonzini <pbonzini@redhat.com> writes:
> >> >
> >> >> On 24/06/2015 17:34, Alex Bennée wrote:
> >> >>> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
> >> >>> leaving one CPU spinning forever waiting for the second CPU to wake up.
> >> >>> We simply need to poke the halt_cond once we have processed the PSCI
> >> >>> power on call.
> >> >>>
> >> >>> Tested-by: Alex Bennée <alex.bennee@linaro.org>
> >> >>> CC: Alexander Spyridakis <a.spyridakis@virtualopensystems.com>
> >> >>>
> >> >>> ---
> >> >>> TODO
> >> >>> - exactly how does the vexpress wake up it's sleeping CPUs?
> >> >>> ---
> >> >>> target-arm/psci.c | 2 ++
> >> >>> 1 file changed, 2 insertions(+)
> >> >>>
> >> >>> diff --git a/target-arm/psci.c b/target-arm/psci.c
> >> >>> index d8fafab..661ff28 100644
> >> >>> --- a/target-arm/psci.c
> >> >>> +++ b/target-arm/psci.c
> >> >>> @@ -196,6 +196,8 @@ void arm_handle_psci_call(ARMCPU *cpu)
> >> >>> }
> >> >>> target_cpu_class->set_pc(target_cpu_state, entry);
> >> >>>
> >> >>> + qemu_cond_signal(target_cpu_state->halt_cond);
> >> >>
> >> >> That's called qemu_cpu_kick(target_cpu_state). :) The patch should be
> >> >> acceptable now upstream, I think.
> >> >
> >> > Oh so this might well fail in KVM too?
> >>
> >> In KVM we won't use target-arm/psci.c because PSCI calls
> >> are handled in the kernel.
> >>
> >
> > It's also not valid to use Alexander's test on KVM, as the test
> > framework doesn't enable the mmu, and thus {ldr,str}ex won't work
> > as expected.
> >
> > I guess I need to do a better job at advertising/documenting
> > kvm-unit-tests/arm, as that framework would suit this test just
> > fine. I've attached a patch porting the test over to k-u-t[1].
> > After applying the patch, do
> >
> > ./configure --arch=arm64 --cross-prefix=aarch64-linux-gnu-
> > OR
> > ./configure --arch=arm --cross-prefix=arm-linux-gnu-
> >
> > make
One more step here, that you probably already figured out
export QEMU=<path-to-qemu-you-want-to-test>
> >
> > arm/run arm/vos-spinlock-test.flat -smp 4 # non-atomic locks
> > OR
> > arm/run arm/vos-spinlock-test.flat -smp 4 -append atomic # atomic
> > locks
>
> Thanks for that. I shall have a play with it today.
Feel free to make suggestions/patches for the framework, and, of course,
to write unit tests :-)
drew
>
> >
> > Thanks,
> > drew
> >
> > [1] git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
>
> --
> Alex Bennée
>
>
next prev parent reply other threads:[~2015-06-26 8:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 15:34 [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (MTTCG) Alex Bennée
2015-06-24 16:01 ` Paolo Bonzini
2015-06-24 17:18 ` Alex Bennée
2015-06-24 17:23 ` Paolo Bonzini
2015-06-24 18:15 ` Alex Bennée
2015-06-24 19:12 ` Peter Maydell
2015-06-25 15:44 ` Andrew Jones
2015-06-26 7:06 ` Alex Bennée
2015-06-26 8:05 ` Andrew Jones [this message]
2015-06-24 23:55 ` Alexander Spyridakis
2015-06-25 6:27 ` Alex Bennée
2015-06-25 12:43 ` Frederic Konrad
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=20150626080538.GD3682@hawk.localdomain \
--to=drjones@redhat.com \
--cc=a.spyridakis@virtualopensystems.com \
--cc=alex.bennee@linaro.org \
--cc=fred.konrad@greensocs.com \
--cc=mark.burton@greensocs.com \
--cc=mttcg@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).