qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Joey Carlini <moocow1452@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] ChrEMU - Virtualization in the Browser
Date: Mon, 23 Sep 2013 17:24:46 +0100	[thread overview]
Message-ID: <p1wqm71p69.fsf@linaro.org> (raw)
In-Reply-To: <20130923133930.GA10376@stefanha-thinkpad.redhat.com>


stefanha@gmail.com writes:

> On Tue, Sep 10, 2013 at 08:08:22PM -0400, Joey Carlini wrote:
>> I managed to get QEMU running on a Crouton install, virtual box not being
>> possible with the Chrome OS kermel with the KVM mods required, and even a
>> couple distros running. Since I enjoy pain and/or haven't done enough cool
>> things to be called a badass dev, I figured, why not try building QEMU into
>> a Chrome app, now that packaged apps are a thing, and native client allows
>> for C code to run within the browser, letting an entire VM run on a stock
>> Chromebook.
>
> QEMU isn't pure C code and effort would be required to make it run under
> Native Client.

I'm also not sure what it would gain you over the crouton based set-up
(I assume your using VNC for your framebuffer)?

> I've never used Native Client but I think its machine code verifier
> checks the application to ensure that control flow is safe.  In other
> words, low-level things that QEMU does like code generation or stack
> switching are probably not allowed under Native Client since they are
> unsafe!

There is an interesting porting guide worth reading:

https://developers.google.com/native-client/community/porting/MAME

Essentially they had to disable their JIT to get it to compile at all.
Given that a JIT is essence generates new executable opcodes that have
not been vetted by the NaCL tools this would be a big no no.

> Maybe I'm wrong and it's possible, but the first thing to check is the
> constraints that Native Client puts on the application code.

I'm more of an optimist (although I don't know the code as well as
Stefan yet ;-). It is probably possible by disabling TCG and sticking to
the interpreter. However it would be fairly hacky to do and definitely
slower than the crouton based solutions.

It really depends what your use case is? Aside from an exercise in
porting I don't know what else is to gain from going to NaCL. That's no
reason not to try of course!

-- 
Alex Bennée

  reply	other threads:[~2013-09-23 16:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11  0:08 [Qemu-devel] ChrEMU - Virtualization in the Browser Joey Carlini
2013-09-23 13:39 ` Stefan Hajnoczi
2013-09-23 16:24   ` Alex Bennée [this message]
2013-09-23 18:48   ` Anthony Liguori
2013-09-25  8:59     ` Stefan Hajnoczi
2013-09-25 13:10       ` Peter Maydell
2013-09-25 14:02         ` Stefan Hajnoczi
2013-10-07 14:49           ` Paolo Bonzini

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=p1wqm71p69.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=moocow1452@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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).