From: 陳韋任 <chenwj@iis.sinica.edu.tw>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Rajat Goyal <rajat.goyal.90@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Get only TCG code without execution
Date: Fri, 20 Jan 2012 14:38:02 +0800 [thread overview]
Message-ID: <20120120063802.GA66763@cs.nctu.edu.tw> (raw)
In-Reply-To: <CAFEAcA8ajL_d6+hM+AJbyCm=p_ZA1tedp9KyJaGTRbAN4E3piA@mail.gmail.com>
> > I was not talking about semantics of individual instructions but semantics
> > of the whole multi-threaded program. Multi-threaded programs can lead to
> > several different (most of which are unintended) states of the CPU. What
> > states are possible is described in a mathematically rigorous definition of
> > the ARM memory model. My task is to implement this memory model over TCG ops
> > and then compare the results on several different (multi-threaded) litmus
> > tests with the implementation of the memory model over ARM instructions.
>
> Some points to note:
> * The current QEMU code has some known race conditions which can cause
> crashes/hangs in heavily threaded programs in linux-user mode; see eg
> https://bugs.launchpad.net/qemu/+bug/668799
> * We don't really make a serious attempt at implementing the ARM memory
> model in QEMU; our load/store exclusive implementation is pretty hopeless,
> for instance
> * In linux-user mode we basically just pass loads/stores/etc through as
> host-cpu loads/stores, so you get whatever the host's memory model semantics
> are, not what the guest CPU is supposed to do
> * a combination of the above plus the fact we don't implement caches in
> system emulation mode means that our implementation of all the barrier
> insns is a simple no-op; you'll never see barriers at the TCG op level
What's load/store exclusive implementation? And as a general emulator, QEMU
shouldn't implement any architecture-specific memory model, right? What comes
into my mind is QEMU only need to follow guest memory operations when translates
guest binary to TCG ops. When translate TCG ops to host binary, it also has to
be careful not to mess up the memory ordering.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
next prev parent reply other threads:[~2012-01-20 6:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-15 23:09 [Qemu-devel] Get only TCG code without execution Rajat Goyal
2012-01-16 5:32 ` Mulyadi Santosa
2012-01-16 8:41 ` Stefan Hajnoczi
2012-01-16 12:23 ` Rajat Goyal
2012-01-16 12:29 ` Peter Maydell
2012-01-17 1:04 ` 陳韋任
2012-01-17 8:33 ` Peter Maydell
2012-01-19 16:00 ` Rajat Goyal
2012-01-19 16:15 ` Peter Maydell
2012-01-20 6:38 ` 陳韋任 [this message]
2012-01-21 0:21 ` Jamie Lokier
2012-02-02 19:35 ` Rajat Goyal
2012-01-20 6:12 ` 陳韋任
2012-01-20 9:09 ` Peter Maydell
2012-01-20 9:44 ` 陳韋任
2012-01-20 10:46 ` Peter Maydell
2012-01-20 19:40 ` Jamie Lokier
2012-02-06 7:25 ` 陳韋任
2012-02-10 3:08 ` Jamie Lokier
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=20120120063802.GA66763@cs.nctu.edu.tw \
--to=chenwj@iis.sinica.edu.tw \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rajat.goyal.90@gmail.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;
as well as URLs for NNTP newsgroup(s).