Hi Klaus, [+CC Matt]
> 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. Thanks for posting these! I'll have a more thorough look through soon, but wanted to tackle some of the larger design-points first (and we've already spoken a bit about these, but rehashing a little of that for others CCed too). For me, the big decision here is where we want to run the NVMe-MI device model. Doing it in the qemu process certainly makes things easier to set up, and we can just configure the machine+nvme-mi device as the one operation. The alternative would be to have the NVMe-MI model run as an external process, and not part of the qemu tree; it looks like Peter D is going for that approach with [1]. The advantage there is that we would be able to test against closer-to-reality "MI firmware" (say, a device vendor running their NVMe-MI firmware directly in another emulator? are folks interested in doing that?) The complexity around the latter approach will be where we split the processes, and arrange for IPC. [1] suggests at the i2c layer, but that does seem to have complexities with i2c controller model compatibility; we could certainly extend that to a "generic" i2c-over-something protocol (which would also be handy for other things), or go higher up and use MCTP directly as the transport (say, the serial binding over a chardev). The former would be more useful for direct firmware emulation. My interest is mainly in testing the software stack, so either approach is fine; I assume your interest is from the device implementation side? Cheers, Jeremy [1]: https://github.com/facebook/openbmc/blob/helium/common/recipes-devtools/qemu/qemu/0007-hw-misc-Add-i2c-netdev-device.patch