On Mon, 2020-05-18 at 13:18 +0200, Paolo Bonzini wrote: > On 18/05/20 10:45, Anastassios Nanos wrote: > > Being in the kernel saves us from doing unneccessary mode switches. > > Of course there are optimizations for handling I/O on QEMU/KVM VMs > > (virtio/vhost), but essentially what happens is removing mode-switches (and > > exits) for I/O operations -- is there a good reason not to address that > > directly? a guest running in the kernel exits because of an I/O request, > > which gets processed and forwarded directly to the relevant subsystem *in* > > the kernel (net/block etc.). > > In high-performance configurations, most of the time virtio devices are > processed in another thread that polls on the virtio rings. In this > setup, the rings are configured to not cause a vmexit at all; this has > much smaller latency than even a lightweight (kernel-only) vmexit, > basically corresponding to writing an L1 cache line back to L2. > > Paolo > This can be used to run kernel drivers inside a very thin VM IMHO to break up the stigma, that kernel driver is always a bad thing to and should be by all means replaced by a userspace driver, something I see a lot lately, and what was the ground for rejection of my nvme-mdev proposal. Best regards, Maxim Levitsky _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
