I am not sure if this is true. Well, you are not really making a statement that could be easily interpreted. Virtio is specifically created to address performance issues with virtualization. Are you unhappy about the implementation quality or you generally believe that para-virtualization is not the way to go about improving virtualization overhead?

One prime example when with virtio it was possible to get native performance _after_ minimum configuration tuning:

https://serverfault.com/questions/407842/incredibly-low-kvm-...

More details on virtio:

https://vmsplice.net/~stefan/virtio-devconf-2014.pdf

qemu setups often use virtio, afaik virtio was defined by qemu devs, so your statement doesn't really make sense without more details.

Also, "not good enough" kind of needs a definition of a workload and what's "good enough" for it.

It's using virtio-mmio which is less efficient than virtio-pci. But I/O was not a focus of Firecracker, for example it doesn't scale very well because it doesn't do concurrent I/O operations.

I thought virtio was higher performance; why would that make it "not good enough"?

hello guys,

I'm sorry that my first comment was not enough informative.Now, I'm refering to the paper that I read couple of days ago [0]. If you look at the figure 8-9, FC has some issues with IO.

[0]: https://blog.acolyer.org/2020/03/02/firecracker/

> disk read/writes are not good enough

This is an odd thing to say; surely that depends on the application? I doubt most FaaS users are disk IO-bound?

Which of qemu's many disk technologies are you proposing as an alternative?