Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Sparkler – A KVM-Based Virtual Machine Manager (unixism.net)
108 points by shuss on Oct 17, 2019 | hide | past | favorite | 8 comments



Nice writeup!

> The VMM emulates some interesting hardware: a device that can read the latest tweet from Command Line Magic’s Twitter handle, a device that can get the weather from certain cities, another device that can read fetch the latest air quality measurements from certain cities and finally a console device that lets the virtual machine read the keyboard and output text to the terminal.

This is one of the under-appreciated fun things about virtualization: the ability to pretty much make up 'hardware' devices, and completely rethink the way that the hardware should work. No need to be a PC when you can be anything you want. Obviously it's possible to do all the same stuff with hardware, or even kernel drivers, but the KVM interface makes it really easy and fun.


Weirdly no one had done it so far. That's the reason why I cooked up some high level devices :)


> You can program KVM using the well known UNIX file paradigm.

Does anyone know why the API was designed this way? Sending a bunch of ioctls to modify the KVM state seems no better than just having normal function calls for it…


> Sending a bunch of ioctls to modify the KVM state seems no better than just having normal function calls for it

Seeing as how they're mmap()ing the fds, it makes some sense to leverage the other file_operations.


What would "normal function calls" mean? This is happening on the Linux syscall boundary.


Right; why isn’t there a sys_kvm syscall that you can just call from a C program?


It's Linux style. Syscalls are last resort - they're low level and have to be maintained forever. Instead, there are more robust and purpose specific abstractions built on top of them:

- ioctls on char/blkdevs for either physical or logical devices (which also allow for a 'handle' paradigm of operation, and for event polling via epoll/select)

- sysfs and procfs entries for system and process tunables and data

- debugfs for day to day debugging (which is explicitely unstable and not enabled in most production kernels)

- prctl, fcntl, ...

In addition, all of the above is 'automatically' ported across architectures. Some Linux architecture ports have their own syscall tables (with own numbering) and need to be explicitly modified any time a syscall is added.


It it's not the file paradigm, it has to be system calls (plenty of them) set in stone, which could quickly turn into a problem or you probably mean a wrapper library?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: