Re: KVM Clock

2014-12-10 Thread Ryan Stone
On Mon, Jan 20, 2014 at 7:41 PM, Julian Stecklina wrote: > Ah. Thanks. This will do. Something like access_once would be perfect, though. > > I'll post an updated patch that does not duplicate code that is in xen/ > soonish. Didn't get around to testing it the last days. > > Julian I'm interesti

HEADS UP: PCI SR-IOV infrastructure has been committed to head

2015-02-28 Thread Ryan Stone
I've just finished committing support for PCI Single Root I/O Virtualization in the pci subsystem to head. This should be a no-op for everyone right now, but there were some minor refactorings in the pci code that could have a lingering bug. I did make sure to test that it boots on a variety of s

Re: bhyve clock problem, solved by kern.timecounter.hardware="TSC-low" in /etc/sysctl.conf

2015-04-10 Thread Ryan Stone
Using the TSC as the default timecounter in a VM is dangerous. On some hardware, the TSC is not synchronized across all CPU cores. This means that if a VM migrates from one core to another, it could see the timecounter value go backwards. Time jumping backwards can cause all kinds of hilarity.

Re: vmx bug?

2017-05-17 Thread Ryan Stone
The bug that you refer to does not appear to be related to your issue. What does "pciconf -l" print in your FreeBSD VM? ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe,

Re: vmx bug?

2017-05-17 Thread Ryan Stone
On Wed, May 17, 2017 at 7:32 PM, Andrew Vylegzhanin wrote: > > vmx0@pci0:4:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01 > hdr=0x00 > > vendor = 'VMware' > > device = 'VMXNET3 Ethernet Controller' > > class = network > > subclass = ethernet > > vmx1@p

Would there be interest in virtualization of the ixgbe driver?

2011-01-04 Thread Ryan Stone
At $WORK I've implemented an extension of the ixgbe driver that provides multiple virtualized ixgbe interfaces. The implementation uses the 8259[89]'s virtualization features, so the rx and tx paths of the virtual interfaces are completely independent. From the perspective of everything above the

Re: Would there be interest in virtualization of the ixgbe driver?

2011-01-13 Thread Ryan Stone
On Thu, Jan 13, 2011 at 3:04 PM, Brandon Gooch wrote: > It would be nice to split up the hardware for use with vnet jails. The > virtualization technique you are describing -- it sounds similar to > how network device virtualization is done in the Solaris "Project > Crossbow" implementation. Can y

Re: vboxdrv.ko loaded, but no /dev/vboxdrv

2011-10-12 Thread Ryan Stone
On Tue, Oct 11, 2011 at 5:04 PM, G. Paul Ziemba wrote: > Hello wise ones, > > I have the recent (from a few days ago) virtualbox-ose and > virtualbox-ose-kmod ports installed. Other ports are mostly > from Jan, 2011. With vboxdrv.ko loaded, /dev/vboxdrv does not > seem to be created and I don't kn

Re: problems about bhyve

2013-01-21 Thread Ryan Stone
On Mon, Jan 21, 2013 at 6:11 AM, Jesse wrote: > First, I have to load vmm manually. If I write vmm_load="YES" into > /boot/loader.conf and restart the computer, then run ./vmrun.sh vm0, the > whole computer is dead, no keyboard, mouse response. And there is no > response when I press the power bu

SR-IOV Patch Series 2/7: bhyve integration

2014-05-26 Thread Ryan Stone
The bhyve work to interoperate is quite simple. PCI Passthrough through the ppt driver works just fine with SR-IOV VFs. The three changes are: - allow ppt devices to detach. This would happen if the administrator destroyed VFs with iovctl -D - allow the SR-IOV infrastructure to force the ppt dr

Re: SR-IOV Patch Series 2/7: bhyve integration

2014-05-27 Thread Ryan Stone
On Mon, May 26, 2014 at 9:51 PM, Ryan Stone wrote: > http://people.freebsd.org/~rstone/patches/iov/0004-Allow-passthrough-devices-to-be-hinted.patch https://phabric.freebsd.org/D73 ___ freebsd-virtualization@freebsd.org mailing list h

Re: tmpfs panic

2014-07-06 Thread Ryan Stone
On Sun, Jul 6, 2014 at 11:46 AM, Steve Wills wrote: > I should have noted this system is running in bhyve. Also I'm told this panic > may be related to the fact that the system is running in bhyve. > > Looking at it a little more closely: > > (kgdb) list *__mtx_lock_sleep+0xb1 > 0x809638d1