Bug #2360

Wishlist: virtio driver import

Added by vsrinivas over 4 years ago. Updated over 4 years ago.

Status:In ProgressStart date:05/02/2012
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


Tim Bisson ported the FreeBSD virtio-bhyve drivers to DragonFly (https://github.com/bissont/virtio_bhyve). It'd be nice if we could import them into DragonFly.

Status ===
I have started working on integration in the 'virtual' branch of my DragonFly tree:


x 1. Move drivers into appropriate location in source tree + rewrite makefiles

Related issues

Related to Submit #2477: virtio & virtio-blk Driver import Closed


#1 Updated by vsrinivas over 4 years ago


virtio and pci ===
- why is virtqueue_poll() spin-waiting on dequeueing something from a queue? Is this okay?

vballoon ===
- vtballoon_alloc_page is not correct; we need to hold the kernel object, not the vm_token, around page allocation
- the entire balloon device would benefit from conversion to the vm_balloon framework; that is the approach I am using in my tree.

vtblock ===
- get the real FreeBSD CVSID we this was imported from
- why is the disk id # in disk_ops '200'?
- are spinlocks truly the most appropriate lock for the virtio-blk device?

vtnet ===

#2 Updated by vsrinivas over 4 years ago

virtio and pci ====

* subr_sglist is a FreeBSD interface we're pulling it; thesjg has pointed out that XIO fills a similar space. We should look at implementing sglist on top of XIO, so as not to have two different ways of managing ranges of physical addresses.

virtio's vq_ring_enqueue_segments appears to be the main routine depending on the structure of an sglist; virtio-blk just primarily appends pages to a queue. Conversion there would be straightforward (to xio)

Also available in: Atom PDF