On Apr  9 03:58, Chaitanya Kulkarni wrote:
>On 4/8/21 00:52, Padmakar Kalghatgi wrote:
>> On Wed, Apr 07, 2021 at 11:16:02PM +0000, Chaitanya Kulkarni wrote:
>>> On 4/7/21 05:46, Padmakar Kalghatgi wrote:
>>>> Along with this, we planned to implement the sideband MI command handling in QEMU.
>>> why ?
>>>
>>>
>>>
>> Add MI command emulation and avoid HW dependency for development and
>> testing.
>>
>
>Absolutely not. With this logic we have to implement entire NVMe command
>set.Current QEMU implementation is lean, I'd like to keep that way and not
>bloat it just for the sake of testing unless there is a kernel component
>that is consuming MI interface and I don't think so we will have it
>anytime soon.
>

I don't see why this would bloat the nvme device. The out-of-band 
mechanism would necessarily be implemented by a separate qdev device 
that would "listen in" on relevant QEMU busses (PCI, nvme-bus). I expect 
this to look something along the lines of ipmi_sim.

The QEMU nvme device is a PCI device, I don't see that changing. It can 
implement the in-band tunneling mechanism through the NVMe-MI 
Send/Receive commands, but the real work would be handed off to the 
nvme-mi qdev device.

At least I think that's how I would do it.