On Thu, Aug 6, 2020 at 2:38 PM Sergio Lopez <[email protected]> wrote: > On Thu, Aug 06, 2020 at 01:01:30PM +0100, Daniel P. Berrangé wrote: > > On Thu, Aug 06, 2020 at 01:51:48PM +0200, Sergio Lopez wrote: > > > On Thu, Aug 06, 2020 at 11:24:13AM +0100, Stefan Hajnoczi wrote: > > > <snip> > > > > Conclusion > > > > --------------- > > > > Most security bugs in QEMU today are C programming bugs. Switching to > > > > a safer programming language will significantly reduce security bugs > > > > in QEMU. Rust is now mature and proven enough to use as the language > > > > for device emulation code. Thanks to vhost-user and vfio-user using > > > > Rust for device emulation does not require a big conversion of QEMU > > > > code, it can simply be done in a separate program. This way attack > > > > surfaces can be written in Rust to make them less susceptible to > > > > security bugs going forward. > > > > > > > > > > Having worked on Rust implementations for vhost-user-fs and > > > vhost-user-blk, I'm 100% sold on this idea. > > > > > > That said, there are a couple things that I think may help getting > > > more people into implementing vhost-user devices in Rust. > > > > > > 1. Having a reference implementation for a simple device somewhere > > > close or inside the QEMU source tree. I'd say vhost-user-blk is a > > > clear candidate, given that a naive implementation for raw files > > > without any I/O optimization is quite easy to read and understand. > > > > > > 2. Integrating the ability to start-up vhost-user daemons from QEMU, > > > in an easy and portable way. I know we can always rely on daemons > > > like libvirt to do this for us, but I think it'd be nicer to be able > > > to define a vhost-user device from the command line and have QEMU > > > execute it with the proper parameters (BTW, Cloud-Hypervisor already > > > does that). This would probably require some kind of configuration > > > file, to be able to define which binary provides each vhost-user > > > device personality, but could also be a way for "sanctioning" > > > daemons (through the configuration defaults), and to have them adhere > > > to a standardized command line format. > > > > This second point is such a good idea that we already have defined > > how todo this in QEMU - see the docs/interop/vhost-user.json file. > > This specifies metadata files that should be installed into a > > defined location such that QEMU/libvirt/other mgmt app can locate > > vhost-user impls for each type of device, and priortize between > > different impls. > > Nice, but AFAIK QEMU still lacks the ability to process those files > and run the vhost-user device providers by itself. Or perhaps I just > can't find it (?).
How about a Python script? It can list available vhost-user programs and their options: $ qemu-vhost-launcher list vhost-user-gpu Paravirtualized GPU with OpenGL support ...vhost-user-gpu --help output... vhost-user-blk Block device ...vhost-user-blk --help output... You can write a configuration file: $ cat vhost-devices.conf # or yaml/toml/json? [blk1] backend=vhost-user-blk blk-file=/path/to/image.img [iso] backend=vhost-user-blk blk-file=/path/to/installer.iso read-only=true And launch QEMU like this: $ qemu-vhost-launcher run -c vhost-devices.conf -- -M accel=kvm -m 1G -cpu host The 'run' command builds QEMU command-line options for the devices described in the configuration file. It launches the vhost-user device backends and then QEMU. The QEMU vhost-user command-line options (-chardev, -device) are appended to the command-line options. Stefan
