qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Tim Newsham <tim.newsham@gmail.com>
To: QEMU Developers <qemu-devel@nongnu.org>
Subject: [Qemu-devel] forking a virtual machine
Date: Tue, 26 Jul 2016 13:47:00 -1000	[thread overview]
Message-ID: <CAGSRWbhMUsHoDQKSDYfJ7DzWWQH_iog-XDCen4zenP-eDVg7Gw@mail.gmail.com> (raw)

Hi,  We've got an unusual use case for our qemu virtual machines.
We're using a qemu-based system to run a bunch of instrumented
test cases. QEMU provides the instrumented execution environment.
Before we start testing we setup the test environment, which includes
booting an operating system as a guest.  Once everything is ready, we
fork the qemu process once for each test case, with the parent controlling
the test operation while the child performs a test.  (For more details,
see our blog post:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/,
full code
can be found at https://github.com/nccgroup/TriforceAFL)

Right now our fork process is very hacky and gross, because linux
fork() intentionally does not handle forking a multithreaded program.
 We have a special
cpu instruction which triggers the forking to go into test mode.  It sets a
flag, which causes the one and only cpu thread to exit.  Right before it
exits, it sends a signal to the iothread by writing over a pipe.  The
iothread
gets woken up and starts controlling test cases by forking children.
After each fork, it starts up a new cpu to replace the one that exited
before the fork.

This is less than ideal for several reasons.  Most importantly for us, we
would like to be able to communicate informatoin about new JITs that
occur from the child back to the parent so that the parent can reproduce
the JIT and save future children from having to keep JITting the same
thing.  This doesnt currently work (I think because the cpu has exited,
and there is no cpu left in the parent process).

We would also like to have more elegant forking code.

And so my question here -- Is there a better solution that we could use
to support forking a qemu VM?  Are there any single-threaded variants of
qemu that would work well here?  Are there any interesting tricks to pause
and resume a cpu across forks in a clean fashion?  Has anyone else
already worked on this problem?

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

                 reply	other threads:[~2016-07-26 23:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAGSRWbhMUsHoDQKSDYfJ7DzWWQH_iog-XDCen4zenP-eDVg7Gw@mail.gmail.com \
    --to=tim.newsham@gmail.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).