VirtIO DRM Window Server Support: Letting Guest VMs Interface With Host's Compositor

[Hasenpfote]

Yeah it would, but there would be a ton of magic involved.

Well, then call these guys Wizards or Warlocks:

https://looking-glass.hostfission.com/

https://forum.level1techs.com/t/a-little-teaser-of-what-is-to-come/121641/499

Code:

https://github.com/gnif/LookingGlass

Essentially they are copying the framebuffer to a shared memory on the Windows guest. On the host, this is mapped onto an OpenGL plane and then rendered.
Speed is like native! This has been implemented by one guy (+ support from several others) I think. Within two months!

Here is a video of an early alpha build

https://youtu.be/1MI1s4hZ_yE?t=285

This is THE feature people want for Linux!
Finally gaming in Linux without dual booting or having a second screen on the graphic card.
Yes, you still need a second graphic card.

I don't understand why VMware, Oracle and Microsoft did not came up with it.
Luckily they didn't and those guy release it under GPL.

[starshipeleven]

So this may have absolutely nothing to-do with supporting other operating systems but instead provide a path for host/Domain 0 to multiplex cheaper GPU units for acceleration in a generic vendor neutral way so help in price negations in future with GPU vendors.

Wait.
1. it's done on the ChromeOS kernel, and Google isn't running that thing in cloud VMs unless I'm mistaken.
2. this works for integrating a Wayland application on the host's compositor, which makes it look native. Not providing acceleration to the application.

Last time I checked Wayland applications are responsible of their own rendering, so they make OGL or Vulkan calls on their own, render the frame of their window, then send this frame to the compositor that deals with it to create the full screen image. Sooo, this can't be accelerating. It can only be integrating applications from host and guest(s) running Wayland in the most native way possible. Because the application (in the VM) still needs to have access to a GPU (real or otherwise) through other means to render itself first, which is outside of the scope of this feature.

[oiaohm]

You are quoting the wrong person, I said this is clearly made for linux host + linux guest setups.

Completely unnecessary, more often than not you just need a chroot to do that.

It's also completely pointless for their usecase, they make no money on Linux applications, neither directly nor with ads services. Google isn't a cartoon evil character like Microsoft or Omnomnomnomnomnomracle, but they still need to monetize their efforts somehow.

Really there is a simple reason for google to be doing exactly what they are doing. Think about the server farm at times it may be useful to be able to run graphical to be more correct use GPU acceleration.

Yes you do have Intel(GVT-g), AMD (MxGPU), and NVIDIA (vGPU). You do have Nvidia with vGPU limiting the cards that support it.

So this may have absolutely nothing to-do with supporting other operating systems but instead provide a path for host/Domain 0 to multiplex cheaper GPU units for acceleration in a generic vendor neutral way so help in price negations in future with GPU vendors.

It always simple to forget google runs a huge server farm and it also simple to forget https://cloud.google.com/gpu/ that server farm uses GPU for acceleration. The difference between desktop and high end server is not as large as it use to be. The introduction of server farms using GPU acceleration moved things in a big way. ChromeOS and Android have been good places for Google to try stuff out some makes it back into their server farms.

There is the problem with Fuchsia idea. Yes Fuchsia has it own kernel?? wait does it. Why are Google developers careful to mention both. When you read the Fuchsia Template Library(FTL) you find out something interesting there is no such thing as a Fuchsia only application as all Fuchsia applications have to be built against the FTL and that is platform neutral. At this point everything should start to make sense. So Fuchsia is a experimental space with no trust that it will be using the prototype kernel included with it in future and it designed particularly that you can scrap the kernel at any time. So Fuchsia can fact will run on a Linux kernel. Really those putting up Fuchsia as some form of serous threat have not done their homework. It will take many more years before we will be sure what path Fuchsia is taking and that may or may not include the micro kernel. The documentation and code about Fuchsia makes that clear.

Now lets think for a moment about the company Collabora who is working on bring virtio_wl to Linux kernel main how it a use to them. Collabora works on Libreoffice online. Does Libreoffice online depend on gpu acceleration at all for best performance? Scary answer yes like opencl for calc. It could also be useful for build farm costs for Collabora and allow broader gpu version testing for Linux desktop and Server versions of their CollaboraOffice line(that is based off libreoffice).

Lightweight container is not much usage when you need to be testing against multi kernel versions or exact as operating systems are deployed.

This is one of those things that you could have predicted someone would implement at some point mainline because it basically makes sense.

[starshipeleven]

What if this is Google's way of teaching their own non-Linux version of the Google OS to interact seamlessly with 'legacy' Linux-based desktop OSes?

Yeah, this is also another possible reason, but that's something very future for now.

Say what you will about Linux, but it is hard to argue that it isn't becoming increasingly legacy in terms of its design, now that it has been demonstrated that you can create performant micro-kernel OSes.

I don't see how Linux design is legacy, beyond your personal dislike for monolithic kernels.
Also micro-kernels have no way to ensure that drivers for them are written with any amount of quality, unlike with Linux. Open drivers do have to conform to kernel code quality standards.

[starshipeleven]

Everyone here seems to be thinking about Windows. Guys, this was done by the ChromeOS folks.

You are quoting the wrong person, I said this is clearly made for linux host + linux guest setups.

What I see as being the purpose of this is to allow you to easily and seamlessly run normal Linux apps in ChromeOS on your Chromebook. You can use ChromeOS and run some other Linux distro in a virtual machine and have the various gui apps running in there show seamlessly like normal windows in ChromeOS.

Completely unnecessary, more often than not you just need a chroot to do that.

It's also completely pointless for their usecase, they make no money on Linux applications, neither directly nor with ads services. Google isn't a cartoon evil character like Microsoft or Omnomnomnomnomnomracle, but they still need to monetize their efforts somehow.

Although I still fail to see why they prefer a virtual machine over a chroot / lightweight container.

The only thing that is a Linux system but is alien enough to require some sort of VM setup is Android.
And Google did say they were working on running Android apps in ChromeOS, and hey have some setup to do that but it's not good enough.

[ermo]

Everyone here seems to be thinking about Windows. Guys, this was done by the ChromeOS folks.

What I see as being the purpose of this is to allow you to easily and seamlessly run normal Linux apps in ChromeOS on your Chromebook. You can use ChromeOS and run some other Linux distro in a virtual machine and have the various gui apps running in there show seamlessly like normal windows in ChromeOS.

Although I still fail to see why they prefer a virtual machine over a chroot / lightweight container. It should be easier to install the distro of your choice in a chroot (like what you can already do with crouton) and expose a connection to the wayland compositor into it, so that you can then launch wayland apps from within the chroot and they will just connect to ChromeOS's wayland compositor. I don't understand why they are instead going for the complexity of dealing with virtual machines and having to use special drivers to cross the boundary between two operating systems.

(emphasis mine)

What if this is Google's way of teaching their own non-Linux version of the Google OS to interact seamlessly with 'legacy' Linux-based desktop OSes?

Google is building its own NextGen micro-kernel-based OS that isn't Linux (the kernel is apparently called Zircon and the OS is called Fuchsia), and in that scenario, it would make all the sense in the world to teach this OS to display Linux apps running on Wayland in a VM?

Say what you will about Linux, but it is hard to argue that it isn't becoming increasingly legacy in terms of its design, now that it has been demonstrated that you can create performant micro-kernel OSes.

[tajjada]

I also assume in the future would be possible to pass each windows from the VM compositor to the host compositor as a series of buffers, so like on Mac VM Fusion you can have applications from the VM running as a window in the host compositor seamlessly.

I thought that this is exactly the point of this project. I.e it is not "in the future", this is exactly what it does.

Yeah it would, but there would be a ton of magic involved.

This can map Linux applications running in the guest to the Linux compositor running in the host, and this is great and all, but Windows applications aren't designed to interface with Linux compositors, so they won't work.

Unless someone replaces the whole Windows GUI components with a dedicated compatibility layer.

MORE LAYERS OF REDIRECTION FOR THE ABSTRACTION GOD!!!!

Everyone here seems to be thinking about Windows. Guys, this was done by the ChromeOS folks.

What I see as being the purpose of this is to allow you to easily and seamlessly run normal Linux apps in ChromeOS on your Chromebook. You can use ChromeOS and run some other Linux distro in a virtual machine and have the various gui apps running in there show seamlessly like normal windows in ChromeOS.

Although I still fail to see why they prefer a virtual machine over a chroot / lightweight container. It should be easier to install the distro of your choice in a chroot (like what you can already do with crouton) and expose a connection to the wayland compositor into it, so that you can then launch wayland apps from within the chroot and they will just connect to ChromeOS's wayland compositor. I don't understand why they are instead going for the complexity of dealing with virtual machines and having to use special drivers to cross the boundary between two operating systems.

[GizmoChicken]

AFAIK (I never really deployed thin clients or similar solutions, so this is my own opinion) RemoteApp is "just" a per-Application RDP session, and RDP has always been superior to most FOSS remote desktop technology, but I don't know how well it runs or if it is comparable to running it in a VM.

Yep, I think "per-Application RDP session" is a good way to describe what RemoteApp provides.

I used a commercial remote desktop solution (maintained by someone else, so I don't know the details) for a while when working with a client. Since I needed to restrict all the work that I did for that client to one desktop, by and large, it made more sense for me to display the entire desktop in a single window on my Linux laptop. But for kicks, I would occasionally display Outlook in its own window, and that seemed to work pretty well. Given that I wasn’t doing anything that required intense graphics acceleration, I don’t know whether or not acceleration was even available.

I'll also leave here that (probably dodgy and probably illegally sold) Winserver OEM licenses can be found for 600$, which isn't exactly cheap. I know pretty much everyone uses KMS loaders to "license" their Windows, but hey.

I don’t know whether it was legal, but at one time, a hack (changing some registry settings) allowed using Windows 7 as a RemoteApp host. Also at one time, the “trial period” for the official Windows Server 2012 ISO (downloadable from the Microsoft website) was pretty long (not sure about Windows Server 2016). So a hobbyist could reinstall an official copy of Windows Server every so often, if just experimenting and testing things out.

And for the ethically challenged, there are, as you mentioned, ways to trick Windows Server 2012 into loading and updating without a license. But of course, such an approach would most likely be illegal, and potentially a security risk, and so I definitely advise against using it.

[starshipeleven]

What am I missing?

I guess he has some special needs he isn't mentioning (also why he isn't running the server in a local VM), because most non-3D-heavy applications run fine in a normal local VM with Virtualbox or VMWare, also available in Seamless or Unity mode (respectively) that integrate the application in the host GUI (while it is still technically inside a VM so it cannot see the host's folders.

AFAIK (I never really deployed thin clients or similar solutions, so this is my own opinion) RemoteApp is "just" a per-Application RDP session, and RDP has always been superior to most FOSS remote desktop technology, but I don't know how well it runs or if it is comparable to running it in a VM.

I'll also leave here that (probably dodgy and probably illegally sold) Winserver OEM licenses can be found for 600$, which isn't exactly cheap. I know pretty much everyone uses KMS loaders to "license" their Windows, but hey.

[GizmoChicken]

Yeah it would, but there would be a ton of magic involved.

If johanb envisions incorporating the methods described in the article, then sure, that would probably involve a ton of magic (although maybe less so using an alternative like GVT-g).

But as for using something like RemoteApp (as described here or similar) to simply display on a Linux desktop apps that are running on Windows Server, I'm not sure that I see the need for magic. What am I missing?