From: Andrew Jones <drjones@redhat.com>
To: Alexander Spyridakis <a.spyridakis@virtualopensystems.com>
Cc: mttcg@greensocs.com,
"Claudio Fontana" <Claudio.Fontana@huawei.com>,
"Mark Burton" <mark.burton@greensocs.com>,
"Alvise Rigo" <a.rigo@virtualopensystems.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Jani Kokkonen" <Jani.Kokkonen@huawei.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"KONRAD Frédéric" <fred.konrad@greensocs.com>
Subject: Re: [Qemu-devel] Self-modifying test case for mttcg
Date: Wed, 22 Jul 2015 17:01:17 +0200 [thread overview]
Message-ID: <20150722150117.GF13441@hawk.localdomain> (raw)
In-Reply-To: <20150722123811.GB13441@hawk.localdomain>
On Wed, Jul 22, 2015 at 02:38:11PM +0200, Andrew Jones wrote:
> On Tue, Jul 21, 2015 at 12:58:56PM +0200, Alexander Spyridakis wrote:
> > Hello all,
> >
> > You can find a new self-modifying test case in the following branch:
> > > git clone https://git.virtualopensystems.com/dev/tcg_baremetal_tests.git -b smc_test
> >
> > For each core, the test will run a small assembly snippet which
> > increments a variable. Immediately after, the snippet is modified in
> > memory to increment by 1 or 2 every other loop cycle, then passes
> > execution to the next core. At the end of the test we calculate the
> > expected result and compare it to the actual incremented variable. If
> > all code modifications happened correctly we pass the test.
> >
> > The test case has been tested with upstream QEMU, MTTCG and KVM with
> > success. Next version of the test will include more corner cases, such
> > as changing TBs immediately after code modification, to make sure that
> > we cover every scenario.
> >
> > To run it:
> > > make virt (or virt64/vexpress for other targets)
> > > ~/mttcg/arm-softmmu/qemu-system-arm -nographic -M virt -cpu cortex-a15 -kernel build-virt/image-virt.axf -smp 8
> >
> > Also, by popular demand I started a port of the test for kvm-unit-tests:
> > > git clone https://git.virtualopensystems.com/dev/kvm-unit-tests.git
>
> I took a quick look at this and see issues with the test code. First,
> you're spinning on a stack variable with this,
>
> /* Wait for our turn */
> while(next_cpu != cpu);
>
> next_cpu needs to be global, and incremented atomically. I haven't gotten
> around to adding atomic_add/inc yet, but it would easy, and I'm happy to
> do it, even yet this week.
>
> And, as for the MMU, I see from the comment in your test code that you're
> hitting an exception when trying to modify code. This is because the code
> is mapped readonly in order to use it from usermode. I suggest you modify
> the page tables (see below for how) to map the code writeable. Do this
> before kicking your secondary cpus, so they'll come up ready.
>
> There are other issues you'll need to fix as well though in the test code;
> count should be initialized, result should be volatile, others? I suggest
> you make sure it works for one vcpu first.
>
> For modifying page tables, I think something like this should work for
> you (untested)
>
> #include <asm/setup.h>
> int main(void)
> {
> mmu_set_range_ptes(mmu_idmap, PHYS_OFFSET, PHYS_OFFSET,
> PHYS_END, __pgprot(PTE_WBWA));
> flush_tlb_all();
>
> ...
>
> I look forward to seeing your fixed up kvm-unit-test test posted. Please
> CC me on it.
Just thought of another issue with the unit test. There's no isb()
following the code modification.
>
> drew
>
> >
> > For the kvm-unit-tests version, I have some troubles with caches and
> > the MMU (which is disabled for this test). While TCG and MTTCG work,
> > KVM fails the test with strange results. I will keep looking to find
> > the exact problem.
> >
> > Best regards.
> >
next prev parent reply other threads:[~2015-07-22 15:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 10:58 [Qemu-devel] Self-modifying test case for mttcg Alexander Spyridakis
2015-07-22 12:38 ` Andrew Jones
2015-07-22 13:06 ` Paolo Bonzini
2015-07-22 13:44 ` Andrew Jones
2015-07-22 15:01 ` Andrew Jones [this message]
2015-07-22 23:12 ` Alexander Spyridakis
2015-07-23 10:04 ` Andrew Jones
2015-07-23 14:42 ` Alexander Spyridakis
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=20150722150117.GF13441@hawk.localdomain \
--to=drjones@redhat.com \
--cc=Claudio.Fontana@huawei.com \
--cc=Jani.Kokkonen@huawei.com \
--cc=a.rigo@virtualopensystems.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=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).