WIP: feat: add NVMe driver #91
No reviewers
Labels
No Label
C
Category/Applications
Category/Drivers
Category/General
Category/Kernel
Category/Libraries
Eolite
FASM
FS
HLL
Influence/Settings
Influence/Text/TYPO
IRCC
Kernel
Kind
Breaking
Kind
Bug
Kind
Build
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: KolibriOS/kolibrios#91
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "ramenu/kolibrios:main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds the current implementation of the NVMe driver from https://git.kolibrios.org/GSoC/kolibrios-nvme-driver.
Currently, the driver seems to work fine on QEMU and Virtualbox, at least from mine and @Burer's tests. I also believe VMWare works, but shutdown on VMWare doesn't work as expected (see GSoC/kolibrios-nvme-driver#5). Unfortunately, we haven't had any tests on real hardware, which is why I have decided to not include it in the AUTORUN.DAT for now, but if you want to add it anyways then that's fine with me.
Lastly, I want to thank all the mentors, developers, and testers and give credit where credit is deserved. Most importantly, @punk_joker for guiding me on how to implement the driver and answering most of my questions, @Burer for testing the driver, and @Doczom, @dunkaist, and @Sweetbread for helping answering and troubleshooting the miscellaneous problems that I had.
You still have TODO comments. Will they be implemented?
Also, I don't think it's worth to add special vim comments
@ -0,0 +131,4 @@
mov eax, [prp1]
mov dword [esp + SQ_ENTRY.prp1], eax
movzx eax, [fid]
;or eax, 1 shl 31 ; CDW10.SV
Delete if unnecessary
@ -0,0 +203,4 @@
endp
; See page 117-118 of the NVMe 1.4 specification for reference
; INCOMPLETE
Is the driver still WIP?
@ -0,0 +445,4 @@
sgls dd ?
mnan dd ?
rb 224
subnqn dq ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
->
rq 32
?@ -0,0 +8,4 @@
;; ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
format PE DLL native
format PE DLL native 0.05
adding this value reduces the number of false positives of antiviruses
Most of the TODO comments are just future enhancements. The TODO comment you mentioned in particular is an optional command that I was implementing at one point, but stopped when I realized it wasn't important.
Currently yes, but all of the features have been implemented. By WIP, I mean it could still be significantly optimized. There are however some parts which I do need to properly check and make sure problems don't occur (see nvme.asm line 267) and the interrupt handler for device conflict. In practice, I don't think the interrupt handler conflict is a problem since the driver checks if any commands have been submitted to the queue anyways, but I'm not certain.
Didn't think about that. Thank you. :)
Noted. Thanks.
@ -0,0 +26,4 @@
add esp, 12
end if
}
I think you do not need this file. Use system debug macro like other drivers
@ -0,0 +1138,4 @@
mov word [esi + edx], ax ; Write to CQyHDBL
mov word [edi + NVM_QUEUE_ENTRY.head], ax
; Unlock the mutex now that the command is complete
You decided to leave the spinlock mechanism. It is not a problem. But can you add some to-do comments about replacing it and why we need to do it later? Also, what problem did you face trying to replace it with another mechanism?
It will help to understand a problem to someone who will do some work on the driver.
@ -0,0 +1288,4 @@
inc ecx
cmp ecx, ebx
; TODO: Apply solution given by @punk_joker of checking which device
; generated an interrupt.
Please add some introduction to the problem it is resolving here.
Sure thing. There wasn't really a problem per say, but I was just mostly afraid of making changes which could potentially cause regressions to the already large number of bugs that the driver had. Now that most bugs have been resolved, I'll start working on this once the VMWare issue has been resolved.
As for your other comments, noted. I'll make those changes.
@sdongles, I found a ugly bug prior to line 1290 which will cause the system to freeze if there's more than one NVMe device registered in the system. I'll add a fix for this later today. Thank you for unintentionally helping me spot that. :)
feat: add NVMe driverto WIP: feat: add NVMe driverWIP: feat: add NVMe driverto feat: add NVMe driverfeat: add NVMe driverto WIP: feat: add NVMe driverNevermind, there's another nasty bug I found which only happens under certain circumstances, see GSoC/kolibrios-nvme-driver#7.
Checkout
From your project repository, check out a new branch and test the changes.