[vbox-dev] Pursuing virtio block driver project

[Klaus Espenlaub]

Hi all,

On 18.11.2015 10:50, Michael Thayer wrote:
> Hello Subodh,
>
> (Is that the right way to address you?)
>
> On 18.11.2015 04:40, Subodh Asthana wrote:
>> Hi,
>>
>> We are students studying at Carnegie Mellon University, as part of our
>> course project for Operating System Practicum
>> <https://www.cs.cmu.edu/~412/> we wanted to pursue writing virtio block
>> driver support for VirtualBox. We found the below thread in the
>> developer community (forum) which indicates that virtio block support
>> has not been done yet.
>>
>> https://forums.virtualbox.org/viewtopic.php?f=9&t=30869&sid=79168a99014f0c7921f9caa10e898a17&start=15
>>
>> We checked in the latest source code and found a file VirtioBlk.c in the
>> path src/VBox/Devices/EFI/Firmware/OvmfPkg, which seems to implement EFI
>> BLOCK IO PROTOCOL. Also, there is file VirtioNet.c (in same path) which
>> seems to implement EFI SIMPLE NETWORK PROTOCOL.
>>
>> There is support for backend virtio network driver but no support for
>> backend virtio block driver. We are curious as to why there is still no
>> support for backend virtio block drivers? Is there is any specific
>> reason for the same?

The reason is that VirtualBox provides rather good storage performance 
(to the extent that some people keep claiming we're cheating) without 
the need for paravirtualization (I remember throughput beyond 
100MByte/sec already with the ATA device emulation, in 2006 on rather 
slow hardware compared to what everyone has today).

VirtualBox today supports floppy, ATA, SATA, SCSI and SAS storage 
controllers. We already have NVMe in the pipeline.

Therefore we don't see the need to go for paravirtualization solutions. 
They are quite some work, with no true benefits. To me the biggest 
argument against going for virtio-blk is that only open source OSes 
(Linux, *BSD, ...) would work with it with reasonable effort, and the 
potential performance benefit is most likely tiny. Getting Windows 
installed with virtio-blk is a major headache.

> So far we only have support for virtio-net, and that only for a pre-1.0
> version of the standard.  The relevant files are:
>
> src/VBox/Devices/PC/ipxe/src/drivers/net/virtio-net.c
> src/VBox/Devices/PC/ipxe/src/drivers/net/virtio-net.h
> src/VBox/Devices/PC/ipxe/src/drivers/bus/virtio-pci.c
> src/VBox/Devices/PC/ipxe/src/drivers/bus/virtio-ring.c

You found the wrong files :) These are the virtio-net support for iPXE, 
which isn't all that interesting for learning how the device emulation 
side works. It's about as interesting as the theoretical virtio-blk boot 
support in EFI.

The interesting VirtualBox device emulation stuff is in:
src/VBox/Devices/VirtIO/Virtio.cpp
src/VBox/Devices/VirtIO/Virtio.h
src/VBox/Devices/Network/DevVirtioNet.cpp

virtio-net has made significant progress since we last spent time on it, 
which would probably offer opportunities to improve its performance (and 
I would hope they found a way to reduce the absolutely horrible latency 
in comparison to other NICs, which limits performance in some use 
cases). However, we're generally satisfied with the performance of the 
E1000 emulation. On the popular host/guest OSes it delivers adequate 
throughput, and the drivers generally are included with all relevant 
guest OSes.

This simplifies installation.

> The files under "bus" are the generic parts of virtio handling, but they
> are still very much oriented towards the virtio-net driver.  We haven't
> pursued virtio much because we didn't really feel a need to.  It might
> bring us some benefits, but so far we have always found other things to
> work on which we expected to bring more.
>
> If you are interested in doing this then we would probably be happy to
> integrate it.  To save yourself pain you would probably want to keep us
> in the loop from an early point.  That way we can make sure that your
> code fits in with our coding style and that we like the general concept
> (usually keeping it as similar as possible to existing code is a good
> way to go).  We would also want evidence that the changes have been well
> tested, especially to catch possible regressions in other parts of the
> software.

Right, generally we accept all sensible contributions, even if the 
majority of the users wouldn't benefit from them.

In this particular case I'd encourage you to carefully evaluate if 
there's a significant gain in spending work on such a project, or if 
there's a different project which would have more impact.

Klaus

>
> Looking forward to seeing the results!
>
> Regards,
>
> Michael
>
>>
>> Thanks and Regards,
>>
>> Subodh Asthana
>>