9.1 -> 9.2 virtio drivers

SirDice

SirDice

Administrator
Staff member
Administrator
Moderator
I'm wondering if anybody has tried to upgrade FreeBSD 9.1 to 9.2 while running with emulators/virtio-kmod. FreeBSD 9.2 should have them included now and the port isn't needed anymore. But if I upgrade how can I make sure the correct ones are loaded? If the upgrade goes sour I wouldn't be able to recover and I'd have to reinstall my VPS.
 
First, I'm a noob.

Second, I have upgraded my VPS from 9.1 to 9.2-RC1. I did not disable the virtio-kmod until after the upgrade was complete. Then I removed package for virtio-kmod. I had installed the package from http://people.freebsd.org/~kuriyama/virtio/.

All I know is that it didn't break. :D

I did see a 50% increase in my download speed, but it is still not up to what I have been able to obtain with Debian. I'm seeing ~34 MB/s with FreeBSD 9.2-RC1 and ~60 MB/s with Debian.
 
..sorry forgot to tell that i have edit the "GENERIC" Kernel Config
and saved it with uneeded modules as "custom" but i found no option
of "virtio"?

Forgot to mention that I have edited the GENERIC kernel configuration file and saved it with unneeded modules as 'custom', but I found no option for virtio

Solved!

Inside GENERIC of KERNEL-GENERIC-9.2-FILE was NOT:
Code: 
device          virtio          # Generic VirtIO bus (required)
device          virtio_pci      # VirtIO PCI Interface
device          vtnet           # VirtIO Ethernet device
device          virtio_blk      # VirtIO Block device
device          virtio_scsi     # VirtIO SCSI device
device          virtio_balloon  # VirtIO Memory Balloon device
but I found it in /usr/src/sys/amd64/conf/NOTES
 
SirDice said:
I'm wondering if anybody has tried to upgrade FreeBSD 9.1 to 9.2 while running with emulators/virtio-kmod.
Click to expand...
Funny you should ask ;)

Code: 
gadget:/home/peter $ uname -a
FreeBSD gadget.xxx.com 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255986: Wed Oct  2 23:11:25 CEST 2013     root@gadget.xxx.com:/usr/obj/usr/src92/sys/SECKERNEL  amd64
This is a VPS which I'm using which requires the VirtIO drivers to be present. In fact, the hosting provider themselves have added them to /boot/modules and set up a loader section (in /boot/loader.conf):

Code: 
# TransIP: load virtualization kernel modules
# DO NOT REMOVE LOADING OF VIRTIO DRIVERS BELOW
# YOUR SYSTEM WON'T BE ABLE TO BOOT WITHOUT THEM
virtio_load="YES"
virtio_pci_load="YES"
virtio_blk_load="YES"
if_vtnet_load="YES"
virtio_balloon_load="YES"
Alas, I've build this machine using the source tree and only disabled virtio_scsi in my kernel configuration because I have no use for it. Eventually cleaned up loader.conf as well as /boot/modules.

I'm still testing (actually I consider those finished) but so far the results are just what I expected them to be. Throughput is looking good, there are no weird messages in /var/run/dmesg.boot and so far things work like a charm. From that same dmesg.boot file:

Code: 
virtio_pci0: <VirtIO PCI Network adapter> port 0xc160-0xc17f mem 0xfebf1000-0xfebf1fff irq 11 at device 3.0 on pci0
vtnet0: <VirtIO Networking Adapter> on virtio_pci0
virtio_pci0: host features: 0x711fffe3 <EventIdx,RingIndirect,NotifyOnEmpty,RxModeExtra,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxUFO,TxTSOECN,TxTSOv6,TxTSOv4,RxUFO,RxECN,RxTSOv6,RxTSOv4,TxAllGSO,MacAddress,RxChecksum,TxChecksum>
virtio_pci0: negotiated features: 0x110fbba3 <RingIndirect,NotifyOnEmpty,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxTSOECN,TxTSOv6,TxTSOv4,RxECN,RxTSOv6,RxTSOv4,MacAddress,RxChecksum,TxChecksum>
vtnet0: Ethernet address: 52:54:00:32:f6:a9
virtio_pci1: <VirtIO PCI Network adapter> port 0xc180-0xc19f mem 0xfebf2000-0xfebf2fff irq 11 at device 4.0 on pci0
vtnet1: <VirtIO Networking Adapter> on virtio_pci1
virtio_pci1: host features: 0x711fffe3 <EventIdx,RingIndirect,NotifyOnEmpty,RxModeExtra,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxUFO,TxTSOECN,TxTSOv6,TxTSOv4,RxUFO,RxECN,RxTSOv6,RxTSOv4,TxAllGSO,MacAddress,RxChecksum,TxChecksum>
virtio_pci1: negotiated features: 0x110fbba3 <RingIndirect,NotifyOnEmpty,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxTSOECN,TxTSOv6,TxTSOv4,RxECN,RxTSOv6,RxTSOv4,MacAddress,RxChecksum,TxChecksum>
vtnet1: Ethernet address: 52:54:00:16:70:9a
pci0: <multimedia, audio> at device 5.0 (no driver attached)
virtio_pci2: <VirtIO PCI Block adapter> port 0xc100-0xc13f mem 0xfebf3000-0xfebf3fff irq 10 at device 6.0 on pci0
vtblk0: <VirtIO Block Adapter> on virtio_pci2
virtio_pci2: host features: 0x710006d4 <EventIdx,RingIndirect,NotifyOnEmpty,Topology,WriteCache,SCSICmds,BlockSize,DiskGeometry,MaxNumSegs>
virtio_pci2: negotiated features: 0x10000254 <RingIndirect,WriteCache,BlockSize,DiskGeometry,MaxNumSegs>
vtblk0: 153600MB (314572800 512 byte sectors)
virtio_pci3: <VirtIO PCI Balloon adapter> port 0xc1a0-0xc1bf irq 11 at device 7.0 on pci0
vtballoon0: <VirtIO Balloon Adapter> on virtio_pci3
virtio_pci3: host features: 0x71000002 <EventIdx,RingIndirect,NotifyOnEmpty,StatsVq>
virtio_pci3: negotiated features: 0
Oh, one thing to keep in mind: I have no idea if the TSO bug in if_vtnet has been fixed yet, so right now I'm still relying on having net.inet.tcp.tso disabled through sysctl.conf.

Other than that no issues.

SirDice said:
But if I upgrade how can I make sure the correct ones are loaded? If the upgrade goes sour I wouldn't be able to recover and I'd have to reinstall my VPS.
Click to expand...
I had to face the same problem (sort off]/boot/kernel[/file] takes priority over /boot/modules.

I'm not sure if that's correct, but as mentioned I had some extra leverage.

Initially I simply went ahead with booting, also knowing that if a module (or function) is already present it (probably) won't get loaded twice. And it worked.

My backup plan was that you can load modules on the loader prompt. As far as I know this also includes modules from the /boot/modules location.


As to your question: I noticed /usr/src/sys/modules/virtio to be present. Although the drivers are enabled in the GENERIC kernel configuration I'm now starting to think that you should also be able to compile them as individual modules.

That's what I'd look into. Compile them as individual modules (so they end up in /boot/kernel) and copy the modules you're currently using to /boot/modules.

I expect things to simply work out (it did for me) but in the case of a problem you should then be able to manually load the modules from /boot/modules using the loader prompt.

Still, I need to stress out: I made some assumptions up there, also because I could roll back to a working setup at any time. So you really should double check this for yourself.

Either way, hope it can give you some ideas.

(edit)

PS: I even used clang to compile the whole lot, it went flawlessly. Right now I can't tell if I'm simply imagining things but I get the feeling that the ports which I've rebuild (just in case) actually build a bit faster than before.

Could be my imagination though. Oh; I'm not using devel/ccache or such.
 
Well, I finally had some time and bit the bullet. Everything went smoothly. I was using a custom kernel and just made sure all the virtio drivers were added to my config. Installation went without a hitch. The drivers from emulators/virtio-kmod didn't interfere, probably because I had them already in my kernel. After the reboot everything worked so I removed the package and rebooted again to make sure.
 
You must log in or register to reply here.
Back
Top