- User Since
- Dec 7 2017, 1:03 PM (146 w, 7 h)
Sun, Sep 20
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.
Fri, Sep 18
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:
Thu, Sep 10
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.
Jun 29 2020
Jun 25 2020
I like your suggestion of explicitly specifying devpath but need to think about the implications especially with regards to backwards compatibility.
Jun 24 2020
Jun 23 2020
Thank you for this contribution!
Overall, I like these changes but would prefer to keep the Controller Data initialization together.