libnvme questions

[Padmakar Kalghatgi]

On Fri, Apr 09, 2021 at 07:48:08AM +0200, Klaus Jensen wrote:
>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.

Yes, I agree with Klaus. The plan is to implement the NVMe-MI command
set and not to implement anything new in the NVMe module of QEMU.