https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082012-05-02T18:57:00ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #2360: Wishlist: virtio driver importhttps://bugs.dragonflybsd.org/issues/2360?journal_id=108052012-05-02T18:57:00Zvsrinivasvsrinivas@ops101.org
<ul></ul><p>TODO:</p>
<p>virtio and pci ===<br />- why is virtqueue_poll() spin-waiting on dequeueing something from a queue? Is this okay?</p>
<p>vballoon ===<br />- vtballoon_alloc_page is not correct; we need to hold the kernel object, not the vm_token, around page allocation<br />- the entire balloon device would benefit from conversion to the vm_balloon framework; that is the approach I am using in my tree.</p>
<p>vtblock ===<br />- get the real FreeBSD CVSID we this was imported from<br />- why is the disk id # in disk_ops '200'?<br />- are spinlocks truly the most appropriate lock for the virtio-blk device?</p>
<p>vtnet ===</p> DragonFlyBSD - Bug #2360: Wishlist: virtio driver importhttps://bugs.dragonflybsd.org/issues/2360?journal_id=108112012-05-05T04:28:14Zvsrinivasvsrinivas@ops101.org
<ul></ul><p>virtio and pci ====</p>
<ul>
<li>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.</li>
</ul>
<p>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)</p> DragonFlyBSD - Bug #2360: Wishlist: virtio driver importhttps://bugs.dragonflybsd.org/issues/2360?journal_id=143412022-06-04T11:16:00Ztuxillo
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/14341/diff?detail_id=3989">diff</a>)</li><li><strong>Category</strong> set to <i>Feature request</i></li></ul><p>None of the links in the description are available anymore.</p>