
Show HN: Sparkler – A KVM-Based Virtual Machine Manager - shuss
https://unixism.net/2019/10/sparkler-kvm-based-virtual-machine-manager/
======
mjb
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.

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

------
saagarjha
> 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…

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

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

~~~
q3k
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.

