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 >> _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
