WEBVTT 00:00.000 --> 00:10.500 So I'm Jorge Toconega from Entity Corporation, and today I will talk about my recent 00:10.500 --> 00:21.400 works for running existing applications on browsers using QMU, and so this is a summary 00:21.400 --> 00:22.400 of the stock. 00:22.400 --> 00:28.960 QMU wasm is QMU experimentally ported to browser, and it runs a modified software as 00:28.960 --> 00:35.080 like a linear things I'd brother, and I'd support PCG, did compiler, networking, and mounting 00:35.080 --> 00:42.880 files, and I will show some of the demos for running Linux VMs, content as Raspberry Pi 00:42.880 --> 00:49.960 inside browser, and first of all, while porting apps too awesome. 00:49.960 --> 00:58.520 So yeah, I think that even if the level aging existing apps on browser is done by a 00:58.760 --> 01:05.840 project in the ecosystem, and it is useful, for example, for dev environment, playground, 01:05.840 --> 01:17.620 building blocks, etc., but porting apps, the browser is not easy, so for example, existing 01:17.620 --> 01:24.840 software as like a Linux applications, they are need to be implemented to run inside 01:24.840 --> 01:25.840 browsers. 01:25.840 --> 01:31.180 For example, maybe we need recompilation to watch them or JavaScript, or some systems 01:31.180 --> 01:39.440 calls might be unavailable inside browser, so here, can we run a modified application inside 01:39.440 --> 01:40.440 browser? 01:40.440 --> 01:49.080 So here, I'm currently working on QMU, this is an experimentally ported QMU to 01:49.080 --> 02:01.520 browser using in scripting, and currently I've tested X8664 and RX64 and RX64, and it 02:01.520 --> 02:08.400 supports T-CGG compiler, and auto mounting files, networking, and the picture in this 02:08.400 --> 02:18.920 slide runs QMU version inside browser, and it runs X8664 Linux inside browser, and QMU 02:18.920 --> 02:25.880 version accepts the same flux as the native QMU, so you can pass flux to QMU via image 02:25.880 --> 02:34.760 correctance, module object in jf, and in the repo, you can find some examples for running 02:34.760 --> 02:43.880 networking using dashnet-f, plug-and-mounting using dash-votative-flug, and migration-incoming 02:43.880 --> 02:45.360 flux. 02:45.360 --> 02:53.360 And in the slide, via the configuration example for QMU version, this starts a VM with 512 02:53.360 --> 03:01.520 megabyte memory with enabling T-CG-G-G-G compiler, and this starts the kernel at specified 03:01.520 --> 03:07.880 by dash-cono-flug, and the root-file system disk image is also provided using dash-drive 03:08.120 --> 03:19.800 so I'm going to show you demo of QMU version, but one of my connections in this room looks 03:19.800 --> 03:33.800 a little bit bad, so I hope it will success, so this is a demo on GitHub page, and you can start 03:33.800 --> 03:40.760 a terminal or virtual machine from this link, and I've already started alpine Linux inside 03:40.760 --> 03:50.440 browser using QMU version with x8664, emulation, and this page runs a QMU version, and alpine Linux 03:50.440 --> 04:02.840 is completely inside browser, so you can find a terminal in this page, and quickly, I will 04:02.920 --> 04:12.360 log into this open Linux at root, and using unem command, you can confirm that this is the 04:12.360 --> 04:21.160 Linux environment with x8664, and by executing what is the release command, you can confirm 04:21.160 --> 04:30.840 this is alpine Linux, and of course you can see the root-file system on slash, and this page also 04:30.840 --> 04:37.240 enables the on browser networking stock, and you can find the yes, this double-get command, 04:37.240 --> 04:48.600 this points to my GitHub page on the internet, and I can access this page from my terminal, 04:49.640 --> 04:58.760 using double-get command, all right, so this page ran double-get and I fetched the HTML 04:58.760 --> 05:13.400 contents from GitHub page, and I print the contents on the terminal, so, so this was a demo, 05:13.400 --> 05:24.440 so how it works, so we've ported QMU system emulator, using emoscript, and the dependency 05:24.440 --> 05:30.760 like a kernel, and root-file system are packaged using emoscript, and that's the payload flag, 05:30.760 --> 05:37.560 and we rely on browser APIs for some features, like a jit compilation, and networking, 05:37.560 --> 05:48.360 and I will describe them in the later slides, so QMU have a jit binary translator called TCG, 05:48.360 --> 05:58.840 and the TCG defines IRR, IRR, or Intamated Rebeventations, and guest code is translated 05:58.840 --> 06:05.640 to IRR by frontend, and IRR is translated to the host code by backend, and the addition 06:05.640 --> 06:13.000 in the right figure, this enables QMU to support a variety of guest and host architectures, 06:13.240 --> 06:19.320 and TCG also supports multiple emulation, utilizing much course on the host, 06:19.320 --> 06:28.760 a difficult multi-threaded TCG, and to support the browser as the host of QMU, 06:28.760 --> 06:34.600 we've added a random backend for TCG, this is a backend for, so, 06:34.600 --> 06:40.120 this takes IRRs and translates them to Watson, addition in the right figure, 06:40.120 --> 06:46.680 and Watson VM has hovered architectures, so, even if backend generates Watson code on memory, 06:46.680 --> 06:52.040 it's not the executable yet, to make it executable, we need to use a browser APIs, 06:53.080 --> 07:00.520 I listed two of them, Rebecebili.module takes a buffer of Watson code and compiles.code, 07:00.520 --> 07:08.280 and Rebecebili.instance, this takes a module and gives a set of functions defined in the Rebecebili code, 07:09.160 --> 07:14.600 and we've also enabled people at support of mscript, and this is actually needed for empty 07:14.600 --> 07:23.480 TCG support, and this compilation based on this browser APIs is actually also used 07:24.680 --> 07:32.200 in other emulators as well, but they're currently only supported to beta guests in a single core 07:32.280 --> 07:41.400 other over now, so we've added a 64-bit guest and empty TCG, and I also briefly introduced 07:41.400 --> 07:51.960 these emulators in the latest light, and in QMU, a unit of instructions to translate 07:51.960 --> 07:58.840 is called Translation Block, or PP, and the Watson backend receives TVs, and it translates 07:58.920 --> 08:07.000 the TV to an executable Watson module, and here Watson backend translates on IR instruction 08:07.000 --> 08:13.880 to the corresponding Watson instructions, we also implemented 64-bit instructions, 08:14.440 --> 08:22.200 this is actually needed to support again, 64-bit guest and empty TCG, and other shown in the 08:22.200 --> 08:34.280 figure, for example, in the lift at i64 IR instruction is translated to i64.at Watson instruction, 08:34.680 --> 08:42.120 and Watson code also contains get-in-set instructions for handling variables, and KMU memory is also 08:42.120 --> 08:50.440 imported to the TV module, so memory related IR instructions can still be used in the Watson 08:50.520 --> 08:59.160 or can also be translated to Watson code, and code in TV sometimes need to call functions provided 08:59.160 --> 09:05.560 by QMU, for example, for fine from a TV, sometimes it needs to find the next TV to change, 09:05.560 --> 09:11.400 using functions provided by QMU, and that these functions provided by QMU are called 09:11.480 --> 09:20.760 help of functions, and this help of functions are also imported to TV, so Watson TV code 09:20.760 --> 09:32.040 can still access necessary help of functions provided by QMU, and however there are some 09:32.040 --> 09:36.920 considerations when creating Watson modules, a lot of Watson modules for each TV, 09:37.880 --> 09:44.200 first one is that the compilation overhead can be ignored, and it's actually slowed down the 09:44.200 --> 09:53.000 execution of the guest code, and the second one is that rather, as of now, are not capable of creating 09:53.000 --> 10:01.560 thousands of modules, a lot of modules, so to mitigate for these considerations QMU, Watson enables 10:01.640 --> 10:09.640 both of wasn't backhand and TCI, TCI is a QMU, I are interplicated through was and other 10:09.640 --> 10:18.440 buckets, so all TV are by default run on TCI, interplitan mode, and TV running many times, 10:18.440 --> 10:24.440 like a thousand times, are considered of hot TVs, and they are compiled to Watson, 10:25.080 --> 10:33.720 and in the following slide, I will show the performance benefit, thanks to QMU's 10:33.720 --> 10:40.680 GIT and Multi-Cosupport, this experiment made a duration to GVIP compressed to megabyte random 10:40.680 --> 10:47.720 data using PIGZ or QMU Watson, and the PIGZ is a GVIP implementation with multi-process 10:47.800 --> 10:54.920 support, this experiment compares QMU Watson and BoX, ported browser with M script and 10:55.720 --> 11:05.480 box is a portable X86 emulator with interplitan approach, and this is a duration for running PIGZ, 11:06.200 --> 11:13.800 box took over 40 seconds for completing the command, QMU completed this command in about 11:14.360 --> 11:21.800 30 seconds, which is much faster than BoX, and we also enabled four threads, MTTCG, 11:21.800 --> 11:29.000 so it leveled with multiple core on the host, so performance is improved more, and it took about 11:29.640 --> 11:38.440 seven or eight seconds, and QMU wasn't more to support device emulation features, 11:38.760 --> 11:47.640 thanks to QMU, firstly, QMU Watson supports mounting files from j's code to the guest VM, 11:48.200 --> 11:55.960 so M script then provides its own file system as fs API or fs object in the JavaScript, 11:55.960 --> 12:04.360 and QMU Watson can mount fs object to the guest, so for example in this slide, 12:05.000 --> 12:15.080 we add the file slash shear slash file to the file system of M script, and it contains a string 12:15.640 --> 12:23.000 test, and then QMU Watson can mount it to the guest using dash, dash, vr, fs, vr, and other 12:23.000 --> 12:31.960 mounting flux, with specifying the slash shear directly, and in the guest that directly can be mounted 12:32.040 --> 12:43.800 for your 9p, and the guest can access to that file, and QMU Watson also supports 12:44.760 --> 12:49.640 networking with two missiles, first one is web socket based approach, which runs into 12:49.640 --> 12:55.800 working stocking outside with browser, and another one is fetch API based approach, which runs 12:55.800 --> 13:00.760 networking stock inside of the browser, I have described each of them in the following slides. 13:02.280 --> 13:09.160 First one is web socket approach, as we shown in the figure, we run the networking stock outside 13:09.160 --> 13:16.120 of the browser, QMU and networking stock on the host are connected via web socket, 13:16.120 --> 13:19.560 probably these approaches, destinations are not limited by browser, 13:19.560 --> 13:25.240 browser has a lot of limitations about destinations to connect, but currently the main 13:25.240 --> 13:34.680 dinner's cost of networking stock demon on the host. The second approach is using fetch API, 13:34.680 --> 13:41.240 this second approach, so as I'm showing in the figure, we run the networking stock inside 13:41.240 --> 13:48.520 browser, so the networking stock demon on the host is not needed, so networking stock inside 13:48.520 --> 13:59.960 browser provides HTTP proxies to the guest VM, and the networking stock inside browser connects 13:59.960 --> 14:05.880 connect to the outside of the browser using fetch API, a product of this approach is easy to maintain, 14:05.880 --> 14:11.960 because we don't need to maintain any demon on the host, but the corner of this approach is 14:11.960 --> 14:20.280 a limited protocol, currently HTTP, HTTP is only, and this also has a reflection by fetch API, 14:21.080 --> 14:26.280 including a limited destination by quarter resolution, where like a four billion head does, 14:26.280 --> 14:35.640 they allow HTTP head does cannot be controlled from the VM, because of the restriction of fetch API. 14:35.640 --> 14:55.640 Okay, maybe this is another demo, I need to show, so, okay, I had to talk about a similar 14:55.720 --> 15:02.600 like a variety of what I said, look at demos, not limited to a virtual machine, a use case, 15:02.600 --> 15:09.880 but first one is like a board emulation, came with support, like a middle thing, a variety of 15:09.880 --> 15:18.360 machines, including boards, and of course, still usable on QMU was a material, and the figure in this 15:18.360 --> 15:26.680 slide shows running emulated Raspberry Pi board inside browser, and I want to quickly show the 15:26.680 --> 15:36.920 demo of this emulation, okay, again, this is also available the GitHub page, so you can 15:36.920 --> 15:47.160 try this demo on your browser, and in this demo, we are running Raspberry Pi board, 15:47.160 --> 16:01.320 emulated inside browser, and this Raspberry Pi board is a busy box, and using a name, 16:01.320 --> 16:10.520 you can confirm that this is also Linux, and this is R64, which is a Raspberry Pi board architecture, 16:10.520 --> 16:25.240 and also, according to CPU, you can confirm that you can confirm also, this is a Raspberry Pi, 16:25.960 --> 16:39.560 I'm elated Raspberry Pi, and also, okay, and the CFFs, we can also find this is a Raspberry Pi 16:39.800 --> 16:50.840 environment, you know, of course, you can still access to the file system, one slash, 16:51.480 --> 16:59.960 and another use case of QMU wasm is running container inside browser, so they are the project 16:59.960 --> 17:06.280 container to wasm, this is the converter of container to wasm block, and things version 0.8, 17:06.280 --> 17:13.400 it provides dash dash to dash j-flac, for enabling QMU wasm, so we knew specify dash dash to dash j-flac, 17:14.440 --> 17:23.480 and you can specify the container to run in the destination directly, in the C2W command package, 17:23.480 --> 17:28.520 all of QMU wasm, and the root file system contain an image, and create a package 17:28.600 --> 17:37.560 to use QMU wasm, plus the root file system environment, and so I'm going to show you 17:39.720 --> 17:51.160 a container running inside browser, okay, so you can see that this is the terminal block 17:51.560 --> 17:57.240 screen, and currently, this browser is fetching container root file system in the QMU, 17:57.240 --> 18:04.200 what is from the server, running on local host, and when it completes, this browser 18:04.200 --> 18:12.520 un-packs everything, un-packs the container root file system, and it builds QMU wasm, and yes, 18:12.520 --> 18:20.920 container is started, and you can see that you can see that this is again the next 18:20.920 --> 18:26.680 environment, according to your name command, and that you can also see the wasm release, 18:27.880 --> 18:35.080 nope, it is 0 as this, okay, this is the deviant container, deviant environment, 18:35.720 --> 18:52.040 in the, of course, you can see the root file system wasm, all right, so future works, 18:53.480 --> 19:01.960 this is actually still in a very early stage of development, in a lot of things to be improved, 19:01.960 --> 19:07.640 in this project, first one is performance and stability, improvement for wasm bucket, 19:07.640 --> 19:14.760 compared to other buckets, other mature buckets, like x86 bucket, wasm bucket is super simple, 19:15.480 --> 19:21.560 compared to these buckets, so we need to fix that and further improvement is needed for this bucket, 19:22.200 --> 19:27.960 and we also need the integration with more QMU futures, for example, 19:28.920 --> 19:36.120 more guest architectures, more sense graphics, and user mode, QM, also interesting to work on, 19:36.120 --> 19:40.840 and the integration with ecosystem is very important, for example, as of now, 19:41.720 --> 19:48.760 accessing to OS packages, like APK, or from inside browser, even not possible, 19:48.760 --> 19:53.480 because of course, this direction, and also, like a container registry, like a Docker hardware, 19:53.480 --> 19:59.560 or something, they cannot be accessed from browser, because of, again, course of this direction, 19:59.560 --> 20:07.240 so we need to fix that to make a more tight integration with ecosystem and on browser version 20:07.240 --> 20:13.160 wasm. So this is, they are related works, first one is V8-T6, this is a 20:14.760 --> 20:21.080 created by Fabian Hema, and it supports a wide variety of guest OSs, and it supports 20:21.400 --> 20:29.160 translation using browser APIs, but it's currently that does not support X86, X86 64 guests, 20:29.160 --> 20:37.480 and the KMJs is created by a not related nanko, it also supports G2 translation, TCHE, 20:37.480 --> 20:43.320 using browser APIs, but I think it's read it, and it does not support 64 pieces, because that's 20:43.400 --> 20:50.280 open now. So this is a summary of this talk, so give me what I'm giving you, experimentally, 20:50.280 --> 20:56.760 put it to browser and run and modify the software, and it supports TCHE, networking, and 20:56.760 --> 21:05.160 amount, KMJ features, and I've shown some of the demos using KMJ. Yep, I think that's all, thank you very 21:05.240 --> 21:19.080 much. So I think I have like a three minutes for Q&A, do you have any questions? Do you have any 21:19.080 --> 21:27.320 plans for basic graphics support? Yeah, that is very, okay, the question is about a roadmap for 21:27.320 --> 21:33.400 like a graphics support, that is very interesting, on browser we can use like a webGL API, 21:33.400 --> 21:39.480 and also we can use a camera or something. So I think it is possible, but we need to, 21:39.480 --> 21:46.520 we need to in some way port like a virtual renderer or something into into browser, using M-script 21:46.520 --> 21:53.880 and something, but I think it's definitely on our plan, yes. Another question? 21:54.840 --> 22:01.080 Are there any plans for Q&A? 22:01.080 --> 22:05.080 But Q&A? 22:05.080 --> 22:06.120 Q&A? 22:06.120 --> 22:08.120 Q&A? 22:08.120 --> 22:10.120 Q&A? 22:10.120 --> 22:12.120 Q&A? 22:12.120 --> 22:14.120 Q&A? 22:14.120 --> 22:16.360 Q&A? 22:16.360 --> 22:17.720 Q&A? 22:17.720 --> 22:19.720 Q&A? 22:19.720 --> 22:21.720 Q&A? 22:21.720 --> 22:22.940 Q&A? 22:22.940 --> 22:23.960 Q&A? 22:23.960 --> 22:25.080 Q&A? 22:25.080 --> 22:30.120 Q&A? 22:30.120 --> 22:33.600 Q&A? 22:33.600 --> 22:36.260 Q&A? 22:36.260 --> 22:38.260 Q&A? 22:38.260 --> 22:39.900 Q&A? 22:39.900 --> 22:41.200 Q&A? 22:41.200 --> 22:43.200 Q&A? 22:43.200 --> 22:45.140 Q&A? 22:45.140 --> 22:47.840 wnoing. 22:47.840 --> 22:49.680 Number one? 22:49.680 --> 22:52.200 I don't have any concrete idea for this, 22:52.200 --> 22:55.600 but this is a super interesting feature plant. 22:55.600 --> 22:57.080 Thank you. 22:57.080 --> 22:58.080 Yes? 22:58.080 --> 23:00.640 I'm going to talk about the required support 23:00.640 --> 23:03.640 for another architecture like MIPS, if I want to, 23:03.640 --> 23:06.680 I support MIPS, because we're using the intermediate 23:06.680 --> 23:10.440 representation, so what would be needed 23:10.440 --> 23:12.520 to support for your architecture? 23:12.520 --> 23:15.880 The question is, are there any guest 23:15.880 --> 23:17.560 won't guest architecture support? 23:17.560 --> 23:18.880 Yeah. 23:18.880 --> 23:22.480 I think this is a strong point of, 23:22.480 --> 23:25.320 or this is a good point of KEMU. 23:25.320 --> 23:28.320 I think we don't need a lot of work 23:28.320 --> 23:32.440 to support additional guest architecture, 23:32.440 --> 23:35.600 because all of them translated to IR, 23:35.600 --> 23:38.760 and yeah, and it wasn't broken only takes IR. 23:38.760 --> 23:43.400 And it doesn't, almost, it doesn't know, 23:43.400 --> 23:46.000 almost anything about the guest architecture, 23:46.000 --> 23:49.960 because DCG takes care of all of them. 23:49.960 --> 23:54.480 So I think additional guest architecture is not so hard. 23:54.480 --> 23:57.320 Actually, I've already added a risk five support, 23:57.320 --> 24:02.440 and I'll ask 60 for support, and it's really nice 24:02.440 --> 24:05.200 I didn't do anything when that's important. 24:05.200 --> 24:08.200 I just changed the comparison of work. 24:08.200 --> 24:13.200 So maybe something will break, I don't know. 24:13.200 --> 24:17.440 So yeah, but I think it is not so hard work. 24:17.440 --> 24:19.040 We do. 24:19.040 --> 24:21.480 Any other question? 24:21.480 --> 24:22.640 Yeah, no question. 24:22.640 --> 24:24.320 So yeah, thank you very much.