[Qemu-devel] ChrEMU - Virtualization in the Browser

[Qemu-devel] ChrEMU - Virtualization in the Browser

[Joey Carlini]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Hi there,

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.


Any insights I need to look into?

[-- Attachment #2: Type: text/html, Size: 568 bytes --]

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Stefan Hajnoczi]

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'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!

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.

Stefan

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Alex Bennée]

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

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

On Sep 23, 2013 8:46 AM, "Stefan Hajnoczi" <stefanha@gmail.com> wrote:
>
> 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'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!

I'm pretty sure coroutines would provide difficult to port too.

Regards,

Anthony Liguori


> 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.
>
> Stefan
>

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Stefan Hajnoczi]

On Mon, Sep 23, 2013 at 01:48:12PM -0500, Anthony Liguori wrote:
> On Sep 23, 2013 8:46 AM, "Stefan Hajnoczi" <stefanha@gmail.com> wrote:
> >
> > 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'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!
> 
> I'm pretty sure coroutines would provide difficult to port too.

The gthread backend should work since it doesn't use stack-switching.

But it seems like a port to NaCl would be a lot slower and more limited
than a native application.

Stefan

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Peter Maydell]

On 25 September 2013 17:59, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Mon, Sep 23, 2013 at 01:48:12PM -0500, Anthony Liguori wrote:
>> I'm pretty sure coroutines would provide difficult to port too.
>
> The gthread backend should work since it doesn't use stack-switching.

...except that the gthread backend doesn't work for anything
except some nebulous testing scenarios.

-- PMM

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Stefan Hajnoczi]

On Wed, Sep 25, 2013 at 3:10 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 25 September 2013 17:59, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Mon, Sep 23, 2013 at 01:48:12PM -0500, Anthony Liguori wrote:
>>> I'm pretty sure coroutines would provide difficult to port too.
>>
>> The gthread backend should work since it doesn't use stack-switching.
>
> ...except that the gthread backend doesn't work for anything
> except some nebulous testing scenarios.

If someone really needs the gthread backend, they can make it work.

In a NaCl world, you don't have POSIX signals anyway so the signal
mask issue with the gthread backend is moot.

Stefan

Re: [Qemu-devel] ChrEMU - Virtualization in the Browser

[Paolo Bonzini]

Il 25/09/2013 16:02, Stefan Hajnoczi ha scritto:
>>>> >>> I'm pretty sure coroutines would provide difficult to port too.
>>> >>
>>> >> The gthread backend should work since it doesn't use stack-switching.
>> >
>> > ...except that the gthread backend doesn't work for anything
>> > except some nebulous testing scenarios.
> If someone really needs the gthread backend, they can make it work.
> 
> In a NaCl world, you don't have POSIX signals anyway so the signal
> mask issue with the gthread backend is moot.

If you don't have signals, you also don't have a way to interrupt the
VCPU thread.  After all the work on making memory dispatch more
thread-friendly is completed, it shouldn't be _that_ hard to run the TCG
VCPU threads outside the big QEMU lock.  But until that is done, you
need POSIX signals to interrupt the VCPU thread (Windows uses the debug
API instead, which is even worse and probably doesn't have a NaCl
equivalent either).

Paolo