qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
To: "kbusch@kernel.org" <kbusch@kernel.org>
Cc: "its@irrelevant.dk" <its@irrelevant.dk>,
	"hreitz@redhat.com" <hreitz@redhat.com>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	"philmd@linaro.org" <philmd@linaro.org>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	"fam@euphon.net" <fam@euphon.net>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"foss@defmacro.it" <foss@defmacro.it>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>,
	"marcel.apfelbaum@gmail.com" <marcel.apfelbaum@gmail.com>
Subject: Re: [PATCH v2 3/5] hw/nvme: add NVMe Admin Security SPDM support
Date: Mon, 1 Sep 2025 03:11:41 +0000	[thread overview]
Message-ID: <9b606dc9fbc403766eb7a925143e8c6b00a9bd3b.camel@wdc.com> (raw)
In-Reply-To: <aLJ7dKOgu-tJvk28@kbusch-mbp>

On Fri, 2025-08-29 at 22:17 -0600, Keith Busch wrote:
> On Thu, Aug 28, 2025 at 05:25:31PM +1000, Wilfred Mallawa wrote:
> > +static uint16_t nvme_sec_prot_spdm_send(NvmeCtrl *n, NvmeRequest
> > *req)
> > +{
> > +    StorageSpdmTransportHeader hdr = {0};
> > +    g_autofree uint8_t *sec_buf = NULL;
> > +    uint32_t transfer_len = le32_to_cpu(req->cmd.cdw11);
> > +    uint32_t transport_transfer_len = transfer_len;
> > +    uint32_t dw10 = le32_to_cpu(req->cmd.cdw10);
> > +    uint32_t recvd;
> > +    uint16_t nvme_cmd_status, ret;
> > +    uint8_t secp = extract32(dw10, 24, 8);
> > +    uint8_t spsp1 = extract32(dw10, 16, 8);
> > +    uint8_t spsp0 = extract32(dw10, 8, 8);
> > +    bool spdm_res;
> > +
> > +    transport_transfer_len += sizeof(hdr);
> > +    if (transport_transfer_len >
> > SPDM_SOCKET_MAX_MESSAGE_BUFFER_SIZE) {
> > +        return NVME_NO_COMPLETE | NVME_DNR;
> > +    }
> > +
> > +    /* Generate the NVMe transport header */
> > +    hdr.security_protocol = secp;
> > +    hdr.security_protocol_specific = cpu_to_le16((spsp1 << 8) |
> > spsp0);
> > +    hdr.length = cpu_to_le32(transfer_len);
> > +
> > +    sec_buf = g_malloc0(transport_transfer_len);
> > +    if (!sec_buf) {
> > +        return NVME_NO_COMPLETE | NVME_DNR;
> > +    }
> > +
> > +    /* Attach the transport header */
> > +    memcpy(sec_buf, &hdr, sizeof(hdr));
> > +    ret = nvme_h2c(n, sec_buf + sizeof(hdr), transfer_len, req);
> > +    if (ret) {
> > +        return NVME_NO_COMPLETE | NVME_DNR;
> 
> The "NO_COMPLETE" is a special -1 value so or'ing it with anything
> doesn't make sense.
> 
> But more importantly, what's supposed to complete it? This is
> supposed
> to be used as a return code when you have an async context to
> complete
> it later, and there doesn't appear to be one here.
Okay I totally misinterpreted it's use-case, and yeah there's no async
context here. I will update the error return values for V3. Thanks for
the feedback!

Regards,
Wilfred

  reply	other threads:[~2025-09-01  3:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28  7:25 [PATCH v2 0/5] NVMe: Add SPDM over the storage transport support Wilfred Mallawa
2025-08-28  7:25 ` [PATCH v2 1/5] spdm-socket: add seperate send/recv functions Wilfred Mallawa
2025-08-28  7:25 ` [PATCH v2 2/5] spdm: add spdm storage transport virtual header Wilfred Mallawa
2025-08-28  7:25 ` [PATCH v2 3/5] hw/nvme: add NVMe Admin Security SPDM support Wilfred Mallawa
2025-08-30  4:17   ` Keith Busch
2025-09-01  3:11     ` Wilfred Mallawa [this message]
2025-08-28  7:25 ` [PATCH v2 4/5] spdm: define SPDM transport enum types Wilfred Mallawa
2025-08-28  7:25 ` [PATCH v2 5/5] hw/nvme: connect SPDM over NVMe Security Send/Recv Wilfred Mallawa

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-all 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=9b606dc9fbc403766eb7a925143e8c6b00a9bd3b.camel@wdc.com \
    --to=wilfred.mallawa@wdc.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=fam@euphon.net \
    --cc=foss@defmacro.it \
    --cc=hreitz@redhat.com \
    --cc=its@irrelevant.dk \
    --cc=kbusch@kernel.org \
    --cc=kwolf@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).