[Bug 242894] bhyve: TCP / network disconnections between 12.0-RELEASE (guest) and 12.1-RELEASE (hypervisor)

2020-03-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242894 Ole changed: What|Removed |Added CC||o...@free.de --- Comment #10 from Ole ---

[Bug 236922] Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS

2020-03-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922 Tommy P changed: What|Removed |Added Attachment #210737|0 |1 is obsolete|

[Bug 236922] Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS

2020-03-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922 Tommy P changed: What|Removed |Added Attachment #210734|0 |1 is obsolete|

[Bug 236922] Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS

2020-03-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922 --- Comment #55 from Tommy P --- Created attachment 212558 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=212558=edit Proper FreeBSD 11.x patch for VirtIO -- You are receiving this mail because: You are the assignee for the

[Bug 236922] Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS

2020-03-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922 Tommy P changed: What|Removed |Added Attachment #212558|0 |1 is obsolete|

[Bug 236922] Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS

2020-03-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922 Tommy P changed: What|Removed |Added Attachment #212556|0 |1 is obsolete|

Re: [RFC] Adding a Rados block driver to bhyve

2020-03-20 Thread Willem Jan Withagen
On 10-3-2020 19:08, Conrad Meyer wrote: On Tue, Mar 10, 2020 at 9:28 AM Willem Jan Withagen wrote: problem that libblock_rbd.so is stripped in such a way that the symbol I need is removed. So either I'm doing it the wrong way, like special options on the symbols oid. However, I think

Re: bhyve: passthrough SMART info from host nvme controller

2020-03-20 Thread Wanpeng Qian
> But as you point out, the only way to have that happen is to remove > capsicum, but that would make byhve overall LESS secure. Yes, Capsicum is a necessary. for now I just don't know how to get around it. I just think on pci_nvme_init, we get the SMART info from real device. and return that

Re: bhyve: passthrough SMART info from host nvme controller

2020-03-20 Thread John-Mark Gurney
Wanpeng Qian wrote this message on Thu, Mar 19, 2020 at 12:09 +0900: > > Can't you do what something like pci_passthru.c does in passthru_init, > > and open /dev/nvme0 in pci_nvme_init? > > Yes, you are correct. but that will make /dev/nvme0 keep open all the time. > I just thinking when guest