Hacker News Reader

9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance.

> The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports.

If you mean vvfat, that hasn't worked in quite a while, and it never supported writes.

> If you're running a Linux host, and you want ultra-quick dev machine booted from your filesystem, User Mode Linux already exists and has way more support and flexibility.

UML tends to bitrot; it's hit or miss whether it even compiles in each new release, and it doesn't get any significant new development. It also relies on ptracing the target process, which is rather awful; unfortunately there's no better way to implement userspace syscalls.

I wonder if UML could be accelerated by adding some new features to the BPF-based seccomp to support syscall emulation? BPF could translate each syscall into some efficient communication to the UML kernel process.

Alternatively, with a 64-bit address space available, UML could learn to do its own memory and process management, and not rely on host Linux processes at all.

I imagine seccomp and ptrace have pretty similar performance, since they both wake the 'host' using a signal, and stay out of the way until their trigger is met. As for UML stability, Debian have been providing packages of it for years, I can't remember the last time I built it directly.

Could you elaborate on 9p/virtio performance? I've had pretty good results booting qemu/kvm VMs with 9p root filesystems...

UML used to have some host kernel patches that were a lot faster for intercepting syscalls. There was never enough interest (even before Vanderpool/Pacifica) to merge it though.

> Could you elaborate on 9p/virtio performance? I've had pretty good results booting qemu/kvm VMs with 9p root filesystems...

The throughput is passable, if you do large enough reads; however, the latency for individual operations is terrible. Try booting via virtio-9p and building a kernel inside the virtual machine, as compared to the host system. Last time I tried it, it took several orders of magnitude longer, due in large part to the latency of simple operations like stat or open/read/close.

On high-latency links, 9P is slow, but on low latency links (like should be provided by QEMU), 9P should be very fast. Looks like a QEMU implementation problem to me.

That being said, calling QEMU's 9P "9P", is a stretch. 9P was designed wit multiplexing in mind, but it's not multiplexed in QEMU, in fact multiplexing in QEMU uses a completely different mechanism. You can't mount QEMU's thing in Plan 9 (unless someone added support for this when I wasn't looking).

I wouldn't find it surprising at all if the fault lies with qemu's implementation rather than with some inherent property of 9p. The performance test I ran was with qemu's virtio 9p implementation: compared to a kernel compile on the host, one in the guest took a few percent longer on a virtual block device, or hundreds of times longer on virtio-9p.

> 9p works from OSes other than Linux; there's a driver for Windows as well.

Do you have a link to the Windows virtio 9p driver? I'm not aware of such a thing existing.

https://code.google.com/p/ninefs/ . I don't know if it supports the virtio transport, but there's a Windows virtio base driver, so it likely wouldn't be difficult to adapt ninefs to use that.

There are several emulated devices simply because there's no way around it (the rtc, PCI bus, uart, etc.). Obviously KVM handles a fair amount of emulation (PIT, IOAPIC) which is very nice.

Although the Linux implementation for 9p isn't great, there's nothing "fundamental" that limits the caching in the guest. For many use cases, you will have no shared mutable state in the host. Think docker: you have some shared read-only state, but the write bits are yours alone. You may cache anything freely.

This project was simply about playing with these ideas (and implementing a VMM using Go). You should check the slides out to understand the gap that I was looking at, but suffice to say I think there's a wide opportunity for something that gives you a process-like model but whose interface is that of a virtual machine. The key point is that you don't really want an ultra-quick "machine", you probably want to run a process ala Docker. I still want it to be contained as a VM however, for security and compatibility reasons.

If you take a glance at Paragraph 1 of the Readme (its the main description for the project), it says, "Its goal is to provide an alternate, high-performance Linux hypervisor for cloud workloads." So you can probably answer your own question about the intentions of this project.

> it forces the guest to do basically no useful caching of its file system

Of a filesystem was the impression I got. The author implied that you could, in addition, mount any block device provided to you in any way you wanted.

> It can't even boot a standard vmlinuz.

It was mentioned at the end that while it won't run the real-mode code therein, it will attempt extract the elf binary and run that.

One could write a Windows IFS driver for 9P if that had some benefit. As it is, there's a Windows IFS FUSE driver that has a 9P server written for it.

You could, but you almost certainly don't want to.. Network filesystems that try to emulate regular filesystem semantics fundamentally suck, not least because you basically can't do any useful caching, and the caching that is done (because it must be done) can introduce very hard to detect bugs (e.g. coherence between a file and its in-memory mapping. If you want to execute a program from the filesystem you need such a mapping).

Ignoring details like the impossibility of loading the kernel (because the Windows kernel requires to be loaded by its own bootloader, which does a lot of setup), you will not be able to boot from 9P.

>but at least it forces the guest to do basically no useful caching of its file system, in order to remain coherent with the host fs.

Sure, but I assume the host/hypervisor is doing the caching on its side, so this may not be a huge loss for the gain.

Is it interesting if only because it's written in a "memory-safe"* language?

* Terms and conditions apply.

Could this in any way explain why Google Cloud does not support Ubuntu?

GCE added Ubuntu support recently:https://cloud.google.com/compute/docs/operating-systems/linu...