- User Since
- Dec 7 2017, 1:03 PM (163 w, 8 h)
Tue, Jan 19
Fri, Jan 8
Mon, Jan 4
Sat, Jan 2
Any feedback on the change of failing_lba to uint8_t ? Does anything else stick out?
Wed, Dec 23
Dec 14 2020
Fixed various endianess issues:
- made log page structure element failing_lba a byte array
- added htole32() conversion in the selftest command
Dec 9 2020
Addressed new-line in the man page and added a swap bytes routine for the device self-test log page
Oops, I missed that. Thanks!
Dec 8 2020
Dec 4 2020
Dec 2 2020
Dec 1 2020
Sep 20 2020
After thinking about this and talking it over with some of the other bhyve developers, the better approach would be to create a new device model specifically for passing commands and data between a real NVMe device and a guest. The new device model (perhaps pci_nvme_proxy.c) might have a small amount of overlap with the NVMe device model with respect to hooking PCI reads and writes and probably queue creation. But the majority of the functionality would be handled by either nvme(4) or cam(3) requests. Using nvme(4) ioctl's as you have is a good model for Admin commands, but you will want to experiment with how best to implement the I/O path. Let me if you have questions.
Sep 18 2020
I'd love to see the addition of a warning, but am happy with these changes.
FWIW, I checked with our NVMe standards person who says:
Sep 10 2020
Aug 24 2020
Aug 12 2020
I'm happy with this change but need to wait for maintainer approval before I commit it
Aug 10 2020
We've successfully tested a slightly modified version this patch with a CentOS-based VM that used RDTSCP on 12.1-RELEASE. Without the patch, the appliance image core dumps. With this patch, it runs correctly. Checked that module unload works. Thank you for fixing this!
Aug 2 2020
Looks good. Thank you for contributing this!
Aug 1 2020
While this is an interesting approach, the fix you proposed in D24202 is more in line with the goal of emulating an NVMe device, and I'd be more comfortable committing those changes.
This looks good to me. Please rebase against the latest and I'd be happy to commit this.
Jul 31 2020
Thank you for determining why some guest OS's (I'm guessing Windows?) believe that the device isn't healthy!
A couple of observations:
- If the backing storage for the namespace isn't an NVMe device, what will this code do?
- Were you able to determine which fields are important to the OS in question? If so, a better approach might be to fix the missing fields in the current implementation. This would have the added benefit of working with a ZVol or file-based backing storage.
Jul 20 2020
Jul 19 2020
Jul 6 2020
As an update, there is work underway to significantly enhance bhyve configuration. Once that lands, it should make many of the concerns here easier to address.