virtio-net-osx
virtio-net-osx copied to clipboard
pmj
Not working with Yosemite.
The current binary isn't codesigned and thus won't load on Yosemite. I've obtained the necessary certificate from Apple, but I haven't had time to make a new, signed release yet, but it's on my list!
Seems that @thedarb beat me to this issue. Thanks for supporting this @pmj! Any timeline for when this might be compatible with Yosemite?
I'm currently working on reproducing and hopefully fixing bug #1. I'd like to include a fix for that in the next release, which I'll then also properly code-sign, which will make the driver load on Yosemite (and without the warning message on Mavericks). Not sure when that will be exactly, but I've now managed to find some time to work on this project again.
This might be a useful temporary fix, though I have not tried it myself.
http://lifepluslinux.blogspot.ca/2014/10/loading-unsigned-kernel-extensions-on.html
@pmj Is there any reason why a quick code-sign can't be done before fixing #1?
@Manouchehri 2 reasons:
- I've been ill for the last months, so on the rare occasions I've had time and energy, I've been working on paid projects. I've got a diagnosis and treatment now, so this side of it is going to be less of an issue from now on.
- It's not exactly a 5-minute job to make a release at the moment. The codesigning itself in particular is annoying because eariler versions of OSX will refuse to load a signed kext. So I need to make 2 versions of the kext, which will need to be able to co-exist and behave correctly on all OSX versions, because you want things to continue working if you upgrade from a pre-codesigning to a codesigning-enabled version. I've at least got myself a decent test system now with VMs running 10.6 through 10.9 which makes build validation a bit easier. (I still need to figure out 10.10 as it doesn't work with the Chameleon bootloader. I hear it's supposed to work with Clover.)
Bug #1 seems to be a Hypervisor issue actually (?) so I'm putting that on hold for now. I'll do my best to get a signed installer out soon!
Glad to hear you're doing better, hope it stays that way.
I'll have more time to test out OS X late next month, so if you haven't had a chance to sign it yet, I'll look into it. I just wanted to check in to make sure we weren't spending our efforts on the same task.
As far as the installer goes, I think the easiest fix would be to run sw_vers -productVersion (e.g., 10.10.2) and use that to pick the signed or unsigned version.
I think in the past few months 10.10 has gotten a lot easier, I remember it being a pain when I tried it last year.
Regarding the installer: the correct way, as far as I'm aware, is to install both versions, the signed one to /Library/Extensions/ and the unsigned one to /System/Library/Extensions, and give them the same bundle identifier but different version numbers. OSX will pick the higher version if given a choice. That way, things don't break when you do an OS upgrade from pre-10.9 to 10.9+.
Anyway, I'll try and get this done soon.
I should add that booting Yosemite with the kext-dev-mode=1 kernel argument will get rid of the codesign check. A temporary measure at best, but if you're desperate to get it working, that should do it.
Just to confirm (as I've been having issues getting virtio working in Yosemite with kext-dev-mode), does the current driver support Yosemite, but is just not signed?
When I tried, the network interface did appear yet it complained of the cable being unplugged.
Yes, that's the only problem. As both I and @pmj mentioned, adding kext-dev-mode=1 to your kernel line will disable signature checking. Not ideal, but works if you need a quick fix.
http://lifepluslinux.blogspot.ca/2014/10/loading-unsigned-kernel-extensions-on.html
Note that the network interface will appear in Network Preferences even when the driver isn't loaded, just as a red dot with "not connected". ifconfig should be able to tell you if the interface actually exists, and you can check with kextstat if the driver is loaded (although you'll need to use ioreg or IORegistryExplorer or IOJones to check that it's actually attached itself to a PCI device).
There does seem to be an issue on some systems where the interface is actually working, but the OS thinks it isn't - see bug #5. I haven't had a chance to try and repro that. I'm not really sure what would be causing that, as the driver interfaces for signalling connected/disconnected are pretty clear and haven't changed since Snow Leopard or so.
I don't have any personal experience with the driver on Yosemite so far, as I haven't got around to setting up a corresponding VM yet. Ethernet device APIs haven't changed much lately though.
[quote]I still need to figure out 10.10 as it doesn't work with the Chameleon bootloader. I hear it's supposed to work with Clover.[/quote]
I have gotten Mac OS X 10.10 running with Chameleon. I wrote up a guide for unRAID users but the steps should be similar for which ever linux system you are using with KVM.
https://macosxvirtualmachinekvm.wordpress.com/guide-mac-os-x-vm-on-unraid/
Looking forward to testing the updated virtIO Ethernet drivers ;)
Any new progress on this?? I've been checking back once a week since March ;P
Nope, sorry. No technical reasons, just life and priorities, basically. Paid work takes precedence, and spare time when I also have the energy to do this is rare at the moment for various reasons.
If anyone else already has a Apple developer account, they could likely submit it themselves and get it signed. You need to go to the Developer ID Certificate for Signing Kexts area and send it.
If no one else here has an account, I can try pinging @robertinant since he's had success with @Energia.
I'm having the same issues as @munnerz with the driver in yosemite, even with kext dev mode enabled. Driver loads and creates en0 but it doesn't seem to attach it to a pci device. System info reports no PCI devices. Has anyone had better luck with this?
FYI, we're working on virtio stuff again thanks to a company wishing to use virtio with OSX guests and funding some development.
Our driver is failing in one of our test VMs running Yosemite, and it looks like the reason is that this specific combination of virtual hardware and software (qemu machine type Q35, OSX Yosemite) seems to cause MSI-X to be enabled on the PCI device. This changes the layout of the virtio device configuration area, which the driver currently doesn't anticipate. We're looking into how to fix this.
The funding is currently not for the network device, but this is a general issue, and I'm hoping we'll find the time to update the network driver to use the new driver stack, thus fixing the issue in virtio-net too.
Thanks for your patience everyone.
(And yeah, we'll be able to release the other virtio drivers as Free Software too, including proper code signing.)
MSI-X Can be disabled via qemu by setting vectors=0 on the network device. Doing this fixes the Cable Unplugged issue for me.
Setting vectors=0 seems to make things work for me with El Capitan as well (wasn't needed with Mavericks). Now if only i could figure out how to make libvirt do that... Needless to say I'm also interested in the status of the other virtio drivers you're working on ;-)
Now if only i could figure out how to make libvirt do that...
Was able to get this to work with libvirt like this:
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.net0.vectors=0'/>
</qemu:commandline>
I can confirm that this works with Sierra. I added the following to my qemu-system-x86_64 options.
-netdev user,id=hub0port0 \
-device virtio-net,netdev=hub0port0,id=eth0 \
-set device.eth0.vectors=0
I was working off of https://github.com/kholia/OSX-KVM and http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ Full thing here: https://gist.github.com/pdxjohnny/55615b6c1fb083fd5f1a1fc4f31c5b39
