From: Hao Wu <hao.a.wu@intel.com>
To: edk2-devel@lists.01.org
Cc: Hao Wu <hao.a.wu@intel.com>, Jiewen Yao <Jiewen.yao@intel.com>,
Ruiyu Ni <ruiyu.ni@intel.com>, Star Zeng <star.zeng@intel.com>
Subject: [PATCH v1 3/3] MdeModulePkg/NvmExpressDxe: Refine PassThru IO queue creation behavior
Date: Thu, 18 Oct 2018 14:42:00 +0800 [thread overview]
Message-ID: <20181018064200.2068-4-hao.a.wu@intel.com> (raw)
In-Reply-To: <20181018064200.2068-1-hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1260
For the PassThru() service of NVM Express Pass Through Protocol, the
current implementation (function NvmExpressPassThru()) will only use the
IO Completion/Submission queues created internally by this driver during
the controller initialization process. Any other IO queues created will
not be consumed.
So the value is little to accept external IO Completion/Submission queue
creation request. This commit will refine the behavior of function
NvmExpressPassThru(), it will only accept driver internal IO queue
creation commands and will return "EFI_UNSUPPORTED" for external ones.
Cc: Jiewen Yao <Jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c | 42 ++++++++++++++++----
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
index c52e960771..0c550bd52c 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
@@ -476,6 +476,7 @@ NvmExpressPassThru (
UINT32 Data;
NVME_PASS_THRU_ASYNC_REQ *AsyncRequest;
EFI_TPL OldTpl;
+ UINT32 CrIoQid;
//
// check the data fields in Packet parameter.
@@ -587,14 +588,39 @@ NvmExpressPassThru (
}
Sq->Prp[0] = (UINT64)(UINTN)Packet->TransferBuffer;
- //
- // If the NVMe cmd has data in or out, then mapping the user buffer to the PCI controller specific addresses.
- // Note here we don't handle data buffer for CreateIOSubmitionQueue and CreateIOCompletionQueue cmds because
- // these two cmds are special which requires their data buffer must support simultaneous access by both the
- // processor and a PCI Bus Master. It's caller's responsbility to ensure this.
- //
- if (((Sq->Opc & (BIT0 | BIT1)) != 0) &&
- !((Packet->QueueType == NVME_ADMIN_QUEUE) && ((Sq->Opc == NVME_ADMIN_CRIOCQ_CMD) || (Sq->Opc == NVME_ADMIN_CRIOSQ_CMD)))) {
+ if ((Packet->QueueType == NVME_ADMIN_QUEUE) &&
+ ((Sq->Opc == NVME_ADMIN_CRIOCQ_CMD) || (Sq->Opc == NVME_ADMIN_CRIOSQ_CMD))) {
+ //
+ // Command Dword 10 should be valid for CreateIOCompletionQueue and
+ // CreateIOSubmissionQueue commands.
+ //
+ if (!(Packet->NvmeCmd->Flags & CDW10_VALID)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ //
+ // Bits 15:0 of Command Dword 10 is the Queue Identifier (QID) for
+ // CreateIOCompletionQueue and CreateIOSubmissionQueue commands.
+ //
+ CrIoQid = Packet->NvmeCmd->Cdw10 & 0xFFFF;
+
+ //
+ // Currently, we only use the IO Completion/Submission queues created internally
+ // by this driver during controller initialization. Any other IO queues created
+ // will not be consumed here. The value is little to accept external IO queue
+ // creation requests, so here we will return EFI_UNSUPPORTED for external IO
+ // queue creation request.
+ //
+ if ((CrIoQid >= NVME_MAX_QUEUES) ||
+ ((Sq->Opc == NVME_ADMIN_CRIOCQ_CMD) && (Packet->TransferBuffer != Private->CqBufferPciAddr[CrIoQid])) ||
+ ((Sq->Opc == NVME_ADMIN_CRIOSQ_CMD) && (Packet->TransferBuffer != Private->SqBufferPciAddr[CrIoQid]))) {
+ DEBUG ((DEBUG_ERROR, "NvmExpressPassThru: Does not support external IO queues creation request.\n"));
+ return EFI_UNSUPPORTED;
+ }
+ } else if ((Sq->Opc & (BIT0 | BIT1)) != 0) {
+ //
+ // If the NVMe cmd has data in or out, then mapping the user buffer to the PCI controller specific addresses.
+ //
if (((Packet->TransferLength != 0) && (Packet->TransferBuffer == NULL)) ||
((Packet->TransferLength == 0) && (Packet->TransferBuffer != NULL))) {
return EFI_INVALID_PARAMETER;
--
2.12.0.windows.1
next prev parent reply other threads:[~2018-10-18 6:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 6:41 [PATCH v1 0/3] NvmExpressDxe: Bug fixes within NvmExpressPassThru() Hao Wu
2018-10-18 6:41 ` [PATCH v1 1/3] MdeModulePkg/NvmExpressDxe: Refine data buffer & len check in PassThru Hao Wu
2018-10-23 8:53 ` Ni, Ruiyu
2018-10-18 6:41 ` [PATCH v1 2/3] MdeModulePkg/NvmExpressDxe: Always copy CQ entry to PassThru packet Hao Wu
2018-10-23 8:54 ` Ni, Ruiyu
2018-10-18 6:42 ` Hao Wu [this message]
2018-10-23 8:53 ` [PATCH v1 3/3] MdeModulePkg/NvmExpressDxe: Refine PassThru IO queue creation behavior Ni, Ruiyu
2018-10-24 0:59 ` Wu, Hao A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181018064200.2068-4-hao.a.wu@intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox