So I'm Jorge Toconega from Entity Corporation, and today I will talk about my recent
works for running existing applications on browsers using QMU, and so this is a summary
of the stock.
QMU wasm is QMU experimentally ported to browser, and it runs a modified software as
like a linear things I'd brother, and I'd support PCG, did compiler, networking, and mounting
files, and I will show some of the demos for running Linux VMs, content as Raspberry Pi
inside browser, and first of all, while porting apps too awesome.
So yeah, I think that even if the level aging existing apps on browser is done by a
project in the ecosystem, and it is useful, for example, for dev environment, playground,
building blocks, etc., but porting apps, the browser is not easy, so for example, existing
software as like a Linux applications, they are need to be implemented to run inside
browsers.
For example, maybe we need recompilation to watch them or JavaScript, or some systems
calls might be unavailable inside browser, so here, can we run a modified application inside
browser?
So here, I'm currently working on QMU, this is an experimentally ported QMU to
browser using in scripting, and currently I've tested X8664 and RX64 and RX64, and it
supports T-CGG compiler, and auto mounting files, networking, and the picture in this
slide runs QMU version inside browser, and it runs X8664 Linux inside browser, and QMU
version accepts the same flux as the native QMU, so you can pass flux to QMU via image
correctance, module object in jf, and in the repo, you can find some examples for running
networking using dashnet-f, plug-and-mounting using dash-votative-flug, and migration-incoming
flux.
And in the slide, via the configuration example for QMU version, this starts a VM with 512
megabyte memory with enabling T-CG-G-G-G compiler, and this starts the kernel at specified
by dash-cono-flug, and the root-file system disk image is also provided using dash-drive
so I'm going to show you demo of QMU version, but one of my connections in this room looks
a little bit bad, so I hope it will success, so this is a demo on GitHub page, and you can start
a terminal or virtual machine from this link, and I've already started alpine Linux inside
browser using QMU version with x8664, emulation, and this page runs a QMU version, and alpine Linux
is completely inside browser, so you can find a terminal in this page, and quickly, I will
log into this open Linux at root, and using unem command, you can confirm that this is the
Linux environment with x8664, and by executing what is the release command, you can confirm
this is alpine Linux, and of course you can see the root-file system on slash, and this page also
enables the on browser networking stock, and you can find the yes, this double-get command,
this points to my GitHub page on the internet, and I can access this page from my terminal,
using double-get command, all right, so this page ran double-get and I fetched the HTML
contents from GitHub page, and I print the contents on the terminal, so, so this was a demo,
so how it works, so we've ported QMU system emulator, using emoscript, and the dependency
like a kernel, and root-file system are packaged using emoscript, and that's the payload flag,
and we rely on browser APIs for some features, like a jit compilation, and networking,
and I will describe them in the later slides, so QMU have a jit binary translator called TCG,
and the TCG defines IRR, IRR, or Intamated Rebeventations, and guest code is translated
to IRR by frontend, and IRR is translated to the host code by backend, and the addition
in the right figure, this enables QMU to support a variety of guest and host architectures,
and TCG also supports multiple emulation, utilizing much course on the host,
a difficult multi-threaded TCG, and to support the browser as the host of QMU,
we've added a random backend for TCG, this is a backend for, so,
this takes IRRs and translates them to Watson, addition in the right figure,
and Watson VM has hovered architectures, so, even if backend generates Watson code on memory,
it's not the executable yet, to make it executable, we need to use a browser APIs,
I listed two of them, Rebecebili.module takes a buffer of Watson code and compiles.code,
and Rebecebili.instance, this takes a module and gives a set of functions defined in the Rebecebili code,
and we've also enabled people at support of mscript, and this is actually needed for empty
TCG support, and this compilation based on this browser APIs is actually also used
in other emulators as well, but they're currently only supported to beta guests in a single core
other over now, so we've added a 64-bit guest and empty TCG, and I also briefly introduced
these emulators in the latest light, and in QMU, a unit of instructions to translate
is called Translation Block, or PP, and the Watson backend receives TVs, and it translates
the TV to an executable Watson module, and here Watson backend translates on IR instruction
to the corresponding Watson instructions, we also implemented 64-bit instructions,
this is actually needed to support again, 64-bit guest and empty TCG, and other shown in the
figure, for example, in the lift at i64 IR instruction is translated to i64.at Watson instruction,
and Watson code also contains get-in-set instructions for handling variables, and KMU memory is also
imported to the TV module, so memory related IR instructions can still be used in the Watson
or can also be translated to Watson code, and code in TV sometimes need to call functions provided
by QMU, for example, for fine from a TV, sometimes it needs to find the next TV to change,
using functions provided by QMU, and that these functions provided by QMU are called
help of functions, and this help of functions are also imported to TV, so Watson TV code
can still access necessary help of functions provided by QMU, and however there are some
considerations when creating Watson modules, a lot of Watson modules for each TV,
first one is that the compilation overhead can be ignored, and it's actually slowed down the
execution of the guest code, and the second one is that rather, as of now, are not capable of creating
thousands of modules, a lot of modules, so to mitigate for these considerations QMU, Watson enables
both of wasn't backhand and TCI, TCI is a QMU, I are interplicated through was and other
buckets, so all TV are by default run on TCI, interplitan mode, and TV running many times,
like a thousand times, are considered of hot TVs, and they are compiled to Watson,
and in the following slide, I will show the performance benefit, thanks to QMU's
GIT and Multi-Cosupport, this experiment made a duration to GVIP compressed to megabyte random
data using PIGZ or QMU Watson, and the PIGZ is a GVIP implementation with multi-process
support, this experiment compares QMU Watson and BoX, ported browser with M script and
box is a portable X86 emulator with interplitan approach, and this is a duration for running PIGZ,
box took over 40 seconds for completing the command, QMU completed this command in about
30 seconds, which is much faster than BoX, and we also enabled four threads, MTTCG,
so it leveled with multiple core on the host, so performance is improved more, and it took about
seven or eight seconds, and QMU wasn't more to support device emulation features,
thanks to QMU, firstly, QMU Watson supports mounting files from j's code to the guest VM,
so M script then provides its own file system as fs API or fs object in the JavaScript,
and QMU Watson can mount fs object to the guest, so for example in this slide,
we add the file slash shear slash file to the file system of M script, and it contains a string
test, and then QMU Watson can mount it to the guest using dash, dash, vr, fs, vr, and other
mounting flux, with specifying the slash shear directly, and in the guest that directly can be mounted
for your 9p, and the guest can access to that file, and QMU Watson also supports
networking with two missiles, first one is web socket based approach, which runs into
working stocking outside with browser, and another one is fetch API based approach, which runs
networking stock inside of the browser, I have described each of them in the following slides.
First one is web socket approach, as we shown in the figure, we run the networking stock outside
of the browser, QMU and networking stock on the host are connected via web socket,
probably these approaches, destinations are not limited by browser,
browser has a lot of limitations about destinations to connect, but currently the main
dinner's cost of networking stock demon on the host. The second approach is using fetch API,
this second approach, so as I'm showing in the figure, we run the networking stock inside
browser, so the networking stock demon on the host is not needed, so networking stock inside
browser provides HTTP proxies to the guest VM, and the networking stock inside browser connects
connect to the outside of the browser using fetch API, a product of this approach is easy to maintain,
because we don't need to maintain any demon on the host, but the corner of this approach is
a limited protocol, currently HTTP, HTTP is only, and this also has a reflection by fetch API,
including a limited destination by quarter resolution, where like a four billion head does,
they allow HTTP head does cannot be controlled from the VM, because of the restriction of fetch API.
Okay, maybe this is another demo, I need to show, so, okay, I had to talk about a similar
like a variety of what I said, look at demos, not limited to a virtual machine, a use case,
but first one is like a board emulation, came with support, like a middle thing, a variety of
machines, including boards, and of course, still usable on QMU was a material, and the figure in this
slide shows running emulated Raspberry Pi board inside browser, and I want to quickly show the
demo of this emulation, okay, again, this is also available the GitHub page, so you can
try this demo on your browser, and in this demo, we are running Raspberry Pi board,
emulated inside browser, and this Raspberry Pi board is a busy box, and using a name,
you can confirm that this is also Linux, and this is R64, which is a Raspberry Pi board architecture,
and also, according to CPU, you can confirm that you can confirm also, this is a Raspberry Pi,
I'm elated Raspberry Pi, and also, okay, and the CFFs, we can also find this is a Raspberry Pi
environment, you know, of course, you can still access to the file system, one slash,
and another use case of QMU wasm is running container inside browser, so they are the project
container to wasm, this is the converter of container to wasm block, and things version 0.8,
it provides dash dash to dash j-flac, for enabling QMU wasm, so we knew specify dash dash to dash j-flac,
and you can specify the container to run in the destination directly, in the C2W command package,
all of QMU wasm, and the root file system contain an image, and create a package
to use QMU wasm, plus the root file system environment, and so I'm going to show you
a container running inside browser, okay, so you can see that this is the terminal block
screen, and currently, this browser is fetching container root file system in the QMU,
what is from the server, running on local host, and when it completes, this browser
un-packs everything, un-packs the container root file system, and it builds QMU wasm, and yes,
container is started, and you can see that you can see that this is again the next
environment, according to your name command, and that you can also see the wasm release,
nope, it is 0 as this, okay, this is the deviant container, deviant environment,
in the, of course, you can see the root file system wasm, all right, so future works,
this is actually still in a very early stage of development, in a lot of things to be improved,
in this project, first one is performance and stability, improvement for wasm bucket,
compared to other buckets, other mature buckets, like x86 bucket, wasm bucket is super simple,
compared to these buckets, so we need to fix that and further improvement is needed for this bucket,
and we also need the integration with more QMU futures, for example,
more guest architectures, more sense graphics, and user mode, QM, also interesting to work on,
and the integration with ecosystem is very important, for example, as of now,
accessing to OS packages, like APK, or from inside browser, even not possible,
because of course, this direction, and also, like a container registry, like a Docker hardware,
or something, they cannot be accessed from browser, because of, again, course of this direction,
so we need to fix that to make a more tight integration with ecosystem and on browser version
wasm. So this is, they are related works, first one is V8-T6, this is a
created by Fabian Hema, and it supports a wide variety of guest OSs, and it supports
translation using browser APIs, but it's currently that does not support X86, X86 64 guests,
and the KMJs is created by a not related nanko, it also supports G2 translation, TCHE,
using browser APIs, but I think it's read it, and it does not support 64 pieces, because that's
open now. So this is a summary of this talk, so give me what I'm giving you, experimentally,
put it to browser and run and modify the software, and it supports TCHE, networking, and
amount, KMJ features, and I've shown some of the demos using KMJ. Yep, I think that's all, thank you very
much. So I think I have like a three minutes for Q&A, do you have any questions? Do you have any
plans for basic graphics support? Yeah, that is very, okay, the question is about a roadmap for
like a graphics support, that is very interesting, on browser we can use like a webGL API,
and also we can use a camera or something. So I think it is possible, but we need to,
we need to in some way port like a virtual renderer or something into into browser, using M-script
and something, but I think it's definitely on our plan, yes. Another question?
Are there any plans for Q&A?
But Q&A?
Q&A?
wnoing.
Number one?
I don't have any concrete idea for this,
but this is a super interesting feature plant.
Thank you.
Yes?
I'm going to talk about the required support
for another architecture like MIPS, if I want to,
I support MIPS, because we're using the intermediate
representation, so what would be needed
to support for your architecture?
The question is, are there any guest
won't guest architecture support?
Yeah.
I think this is a strong point of,
or this is a good point of KEMU.
I think we don't need a lot of work
to support additional guest architecture,
because all of them translated to IR,
and yeah, and it wasn't broken only takes IR.
And it doesn't, almost, it doesn't know,
almost anything about the guest architecture,
because DCG takes care of all of them.
So I think additional guest architecture is not so hard.
Actually, I've already added a risk five support,
and I'll ask 60 for support, and it's really nice
I didn't do anything when that's important.
I just changed the comparison of work.
So maybe something will break, I don't know.
So yeah, but I think it is not so hard work.
We do.
Any other question?
Yeah, no question.
So yeah, thank you very much.