qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Klaus Jensen <its@irrelevant.dk>
Cc: qemu-devel@nongnu.org, "Corey Minyard" <cminyard@mvista.com>,
	"Keith Busch" <kbusch@kernel.org>,
	"Jason Wang" <jasowang@redhat.com>,
	"Lior Weintraub" <liorw@pliops.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Jeremy Kerr" <jk@codeconstruct.com.au>,
	qemu-arm@nongnu.org, "Matt Johnston" <matt@codeconstruct.com.au>,
	"Peter Delevoryas" <peter@pjd.dev>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	qemu-block@nongnu.org, "Cédric Le Goater" <clg@kaod.org>,
	"Klaus Jensen" <k.jensen@samsung.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	gost.dev@samsung.com
Subject: Re: [PATCH v3 0/3] hw/{i2c, nvme}: mctp endpoint, nvme management interface model
Date: Thu, 1 Jun 2023 14:42:58 -0500	[thread overview]
Message-ID: <ZHj0wnVHdY2HzL20@mail.minyard.net> (raw)
In-Reply-To: <20230531114744.9946-1-its@irrelevant.dk>

On Wed, May 31, 2023 at 01:47:41PM +0200, Klaus Jensen wrote:
> From: Klaus Jensen <k.jensen@samsung.com>
> 
> This adds a generic MCTP endpoint model that other devices may derive
> from. I'm not 100% happy with the design of the class methods, but it's
> a start.
> 
> Also included is a very basic implementation of an NVMe-MI device,
> supporting only a small subset of the required commands. Lior (CC'ed) has some
> patches coming up that adds futher support.
> 
> Since this all relies on i2c target mode, this can currently only be
> used with an SoC that includes the Aspeed I2C controller.
> 
> The easiest way to get up and running with this, is to grab my buildroot
> overlay[1]. It includes modified a modified dts as well as a couple of
> required packages.
> 
> QEMU can then be launched along these lines:
> 
>   qemu-system-arm \
>     -nographic \
>     -M ast2600-evb \
>     -kernel output/images/zImage \
>     -initrd output/images/rootfs.cpio \
>     -dtb output/images/aspeed-ast2600-evb-nmi.dtb \
>     -nic user,hostfwd=tcp::2222-:22 \
>     -device nmi-i2c,address=0x3a \
>     -serial mon:stdio
> 
> From within the booted system,
> 
>   mctp addr add 8 dev mctpi2c15
>   mctp link set mctpi2c15 up
>   mctp route add 9 via mctpi2c15
>   mctp neigh add 9 dev mctpi2c15 lladdr 0x3a
>   mi-mctp 1 9 info
> 
> Comments are very welcome!
> 
>   [1]: https://github.com/birkelund/buildroots/tree/main/mctp-i2c
> 
> Changes since v2
> ~~~~~~~~~~~~~~~~
> 
>   - Applied a bunch of feedback from Jonathan:
>     + Moved a lot of internally used structs out of the include headers
>       and into the source files.
>     + Added spec references in various places
>     + Split the patch for i2c_smbus_pec() into its own
>     + Fix a compile error (and bug) in nmi-i2c.c.
> 
>   - From Corey:
>     + Reworked the buffer handling. The deriving devices now returns a
>       pointer to their own buffer that the mctp core copies into.

You didn't do what I asked here, I guess I wasn't clear.  You have:

+static void i2c_mctp_handle_control_set_eid(MCTPI2CEndpoint *mctp, uint8_t eid)
+{
+    mctp->my_eid = eid;
+
+    uint8_t buf[] = {
+        0x0, 0x0, eid, 0x0,
+    };
+
+    memcpy(i2c_mctp_control_data(mctp->buffer), buf, sizeof(buf));
+    mctp->len += sizeof(buf);
+}

That style of programming can lead to buffer overruns as code changes,
as you aren't checking the length of the target buffer.  I don't think
there are any issues now, but as people change the code you might end up
with one if someone gets a length wrong.

What I would like is for you to create a function like:

  i2c_mctp_add_bytes(mctp, buf, len)

that checks that len bytes will fit, then does the addition of the
bytes.  You need to adjust this to fit how you are doing things, and you
probably want one that adds just one byte, but hopefully you get the idea.

I'm sorry to be picky, but I've seen and fixed too many buffer overruns
(including one in the qemu i2c code) in situations like this.  Corey's
rule is: Never add anything to a buffer without checking the length.

Everything else looks good.

-corey

>     + Added a couple of extra debugging trace events.
> 
> Changes since v1
> ~~~~~~~~~~~~~~~~
> 
>   - Fix SPDX-License tag for hw/nvme/nmi-i2c.c (Philippe)
>   - Add some asserts to verify buffer indices (by request from Corey).
>   - Drop short packets that could result in underflow (Corey)
>   - Move i2c_smbus_pec() to smbus common code (Corey)
>   - A couple of logic fixes (patch from Jeremy squashed in)
>   - Added a patch to handle messages with dest eid 0 (Matt)
>     Maybe squash this as well.
> 
> Klaus Jensen (3):
>   hw/i2c: add smbus pec utility function
>   hw/i2c: add mctp core
>   hw/nvme: add nvme management interface model
> 
>  MAINTAINERS                   |   7 +
>  hw/arm/Kconfig                |   1 +
>  hw/i2c/Kconfig                |   4 +
>  hw/i2c/mctp.c                 | 398 ++++++++++++++++++++++++++++++++++
>  hw/i2c/meson.build            |   1 +
>  hw/i2c/smbus_master.c         |  28 +++
>  hw/i2c/trace-events           |  13 ++
>  hw/nvme/meson.build           |   1 +
>  hw/nvme/nmi-i2c.c             | 367 +++++++++++++++++++++++++++++++
>  hw/nvme/trace-events          |   6 +
>  include/hw/i2c/mctp.h         | 137 ++++++++++++
>  include/hw/i2c/smbus_master.h |   2 +
>  include/net/mctp.h            |  28 +++
>  13 files changed, 993 insertions(+)
>  create mode 100644 hw/i2c/mctp.c
>  create mode 100644 hw/nvme/nmi-i2c.c
>  create mode 100644 include/hw/i2c/mctp.h
>  create mode 100644 include/net/mctp.h
> 
> -- 
> 2.40.0
> 
> 


      parent reply	other threads:[~2023-06-01 19:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-31 11:47 [PATCH v3 0/3] hw/{i2c, nvme}: mctp endpoint, nvme management interface model Klaus Jensen
2023-05-31 11:47 ` [PATCH v3 1/3] hw/i2c: add smbus pec utility function Klaus Jensen
2023-05-31 13:13   ` Jonathan Cameron via
2023-06-01 20:34   ` Philippe Mathieu-Daudé
2023-05-31 11:47 ` [PATCH v3 2/3] hw/i2c: add mctp core Klaus Jensen
2023-05-31 14:59   ` Jonathan Cameron via
2023-05-31 15:04     ` Jonathan Cameron via
2023-05-31 11:47 ` [PATCH v3 3/3] hw/nvme: add nvme management interface model Klaus Jensen
2023-05-31 15:39   ` Jonathan Cameron via
2023-06-01 19:42 ` Corey Minyard [this message]

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=ZHj0wnVHdY2HzL20@mail.minyard.net \
    --to=minyard@acm.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=clg@kaod.org \
    --cc=cminyard@mvista.com \
    --cc=gost.dev@samsung.com \
    --cc=its@irrelevant.dk \
    --cc=jasowang@redhat.com \
    --cc=jk@codeconstruct.com.au \
    --cc=k.jensen@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=liorw@pliops.com \
    --cc=matt@codeconstruct.com.au \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peter@pjd.dev \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).