libnvme questions

libnvme questions

[Tony Asleson]

1. There is interest in utilizing the libnvme library for some other
projects, when is an official release of the library planned?

2. Is it planned for nvme-cli to utilize libnvme?

3. Any plans on adding functionality for NVMe management interfaces to
the library, e.g. NVMe Enclosures?

Thanks,
Tony


_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Chaitanya Kulkarni]

(+CC Keith)

On 3/3/21 17:52, Tony Asleson wrote:
> 3. Any plans on adding functionality for NVMe management interfaces to
> the library, e.g. NVMe Enclosures?

I'd add a plug-in for he nvme-cli named mi if Keith is okay with that.

Maintaining a separate utility seems out of scope for nvme-cli to me.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Keith Busch]

On Wed, Mar 03, 2021 at 03:14:02PM -0600, Tony Asleson wrote:
> 1. There is interest in utilizing the libnvme library for some other
> projects, when is an official release of the library planned?
> 
> 2. Is it planned for nvme-cli to utilize libnvme?

This is my bad, I fell behind the task due to mutliple conflicts of
time, but I am back on this right now. The plan is to tag nvme-cli v1.14
within the next few weeks, then make the shift to libnvme integration
on a "2.0" version for future work on the master branch. This would
coincide with an official libnvme stable release.

I honestly do not have enough devices to regression test all the
features, so I will continue to maintain nvme-cli 1.x branches as long
as necessary while ironing out any integration issues.
 
> 3. Any plans on adding functionality for NVMe management interfaces to
> the library, e.g. NVMe Enclosures?

Will be happen to incorporate any features that are in-spec.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Chaitanya Kulkarni]

Keith,

On 3/10/21 12:56, Keith Busch wrote:
>> 3. Any plans on adding functionality for NVMe management interfaces to
>> the library, e.g. NVMe Enclosures?
> Will be happen to incorporate any features that are in-spec.
>

Adding MI support is good idea ? I think it will bloat the basic
functionality.

Can we consider adding MI plug-in for it ?

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Tony Asleson]

On 3/10/21 10:43 PM, Chaitanya Kulkarni wrote:
> Keith,
> 
> On 3/10/21 12:56, Keith Busch wrote:
>>> 3. Any plans on adding functionality for NVMe management interfaces to
>>> the library, e.g. NVMe Enclosures?
>> Will be happen to incorporate any features that are in-spec.
>>
> 
> Adding MI support is good idea ? I think it will bloat the basic
> functionality.
> 
> Can we consider adding MI plug-in for it ?
> 

IMHO having standards based functionality only in the cli as a plugin
diminishes the value of the library.  If a developer is required to fork
& exec the cli for some functionality, just do it for all.

If the size of libnvme is a concern, MI could be built into a separate
library from the same source tree that leverages the base libnvme
library, to allow selective install & use.


_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Keith Busch]

On Fri, Mar 12, 2021 at 09:35:14AM -0600, Tony Asleson wrote:
> On 3/10/21 10:43 PM, Chaitanya Kulkarni wrote:
> > Keith,
> > 
> > On 3/10/21 12:56, Keith Busch wrote:
> >>> 3. Any plans on adding functionality for NVMe management interfaces to
> >>> the library, e.g. NVMe Enclosures?
> >> Will be happen to incorporate any features that are in-spec.
> >>
> > 
> > Adding MI support is good idea ? I think it will bloat the basic
> > functionality.
> > 
> > Can we consider adding MI plug-in for it ?
> > 
> 
> IMHO having standards based functionality only in the cli as a plugin
> diminishes the value of the library.  If a developer is required to fork
> & exec the cli for some functionality, just do it for all.
> 
> If the size of libnvme is a concern, MI could be built into a separate
> library from the same source tree that leverages the base libnvme
> library, to allow selective install & use.

The MI support through the in-band admin queue is totally fine to
support here. If a feature is in-spec, then it has a place in this
library.

MI support over smbus is probably out-of-scope, though.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Hannes Reinecke]

Hi Keith,

On 3/10/21 9:48 PM, Keith Busch wrote:
> On Wed, Mar 03, 2021 at 03:14:02PM -0600, Tony Asleson wrote:
>> 1. There is interest in utilizing the libnvme library for some other
>> projects, when is an official release of the library planned?
>>
>> 2. Is it planned for nvme-cli to utilize libnvme?
> 
> This is my bad, I fell behind the task due to mutliple conflicts of
> time, but I am back on this right now. The plan is to tag nvme-cli v1.14
> within the next few weeks, then make the shift to libnvme integration
> on a "2.0" version for future work on the master branch. This would
> coincide with an official libnvme stable release.
> 
> I honestly do not have enough devices to regression test all the
> features, so I will continue to maintain nvme-cli 1.x branches as long
> as necessary while ironing out any integration issues.
>  
Any updates here?
We've got some changes/reworks pending (the nvme monitor stuff, and also
a new configuration file mechanism with using a json config file), and
it would be good to know what would be the appropriate base for all of this.

We could give you a helping hand in moving nvme-cli over to nvmelib if
that's an issue ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Keith Busch]

On Wed, Mar 31, 2021 at 04:15:24PM +0200, Hannes Reinecke wrote:
> Hi Keith,
> 
> On 3/10/21 9:48 PM, Keith Busch wrote:
> > On Wed, Mar 03, 2021 at 03:14:02PM -0600, Tony Asleson wrote:
> >> 1. There is interest in utilizing the libnvme library for some other
> >> projects, when is an official release of the library planned?
> >>
> >> 2. Is it planned for nvme-cli to utilize libnvme?
> > 
> > This is my bad, I fell behind the task due to mutliple conflicts of
> > time, but I am back on this right now. The plan is to tag nvme-cli v1.14
> > within the next few weeks, then make the shift to libnvme integration
> > on a "2.0" version for future work on the master branch. This would
> > coincide with an official libnvme stable release.
> > 
> > I honestly do not have enough devices to regression test all the
> > features, so I will continue to maintain nvme-cli 1.x branches as long
> > as necessary while ironing out any integration issues.
> >  
> Any updates here?
> We've got some changes/reworks pending (the nvme monitor stuff, and also
> a new configuration file mechanism with using a json config file), and
> it would be good to know what would be the appropriate base for all of this.
> 
> We could give you a helping hand in moving nvme-cli over to nvmelib if
> that's an issue ...

Thank you, yes, that would be appreciated. I've ported it a couple
times, but I keep having to rebase. It's not terribly difficult, but it
takes a lot of time..

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Hannes Reinecke]

On 3/31/21 4:54 PM, Keith Busch wrote:
> On Wed, Mar 31, 2021 at 04:15:24PM +0200, Hannes Reinecke wrote:
>> Hi Keith,
>>
>> On 3/10/21 9:48 PM, Keith Busch wrote:
>>> On Wed, Mar 03, 2021 at 03:14:02PM -0600, Tony Asleson wrote:
>>>> 1. There is interest in utilizing the libnvme library for some other
>>>> projects, when is an official release of the library planned?
>>>>
>>>> 2. Is it planned for nvme-cli to utilize libnvme?
>>>
>>> This is my bad, I fell behind the task due to mutliple conflicts of
>>> time, but I am back on this right now. The plan is to tag nvme-cli v1.14
>>> within the next few weeks, then make the shift to libnvme integration
>>> on a "2.0" version for future work on the master branch. This would
>>> coincide with an official libnvme stable release.
>>>
>>> I honestly do not have enough devices to regression test all the
>>> features, so I will continue to maintain nvme-cli 1.x branches as long
>>> as necessary while ironing out any integration issues.
>>>   
>> Any updates here?
>> We've got some changes/reworks pending (the nvme monitor stuff, and also
>> a new configuration file mechanism with using a json config file), and
>> it would be good to know what would be the appropriate base for all of this.
>>
>> We could give you a helping hand in moving nvme-cli over to nvmelib if
>> that's an issue ...
> 
> Thank you, yes, that would be appreciated. I've ported it a couple
> times, but I keep having to rebase. It's not terribly difficult, but it
> takes a lot of time..
> 
Can you send me your latest attempts?
That should be a good starting point, and probably avoids some work on 
our side ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

libnvme questions

[Padmakar Kalghatgi]

 We would like to propose an implementation of sideband nvme-mi command set  in nvme-cli & QEMU Subsystem. 

   What are we going to target?

·  NVMe-CLI plug-in for MI (sideband)

      Implementation of MI commands as per NVMe MI specification.
      Enabling  to send the MI commands via SMBus\Hardwares\Emulation.
      Implement this as a plugin which will be similar to the ZNS and other plugins. 
      Provide placeholders for users to plug in the hardware library of their choice.

 
Along with this, we planned to implement the sideband MI command handling in QEMU.
If this feature is used as a plugin, it wont have any impact on the existing interfaces which the nvme command uses.
  
Please share your thougths whether to have this feature as a plugin or as a standalone tool, also provide feedback on our plan to have the sideband MI functionality.
We are open to co-work and collaborate on this feature development.

Since most of the companies who develop SSDs, use MI(sideband) channel, we think this will be a good enhancement to the existing functionality which the nvme-cli provides.

Here is a list of SSDs released which uses sideband MI:
ref: https://www.iol.unh.edu/registry/nvme-mi     

WDC SN630 
WDC SN640
WDC SN640
WDC Ultrastar DC SN630 

HGST Ultrastar SN200 

Intel D7-P5500
Intel® Optane™ SSD DC P4800X 
Intel® SSD DC P4500 Series
Intel® SSD DC P4608 Series
Intel® SSD DC P4600 Series
Intel® SSD DC P4501 Series

Samsung NVMe 172X Series 

Thanks,
Padmakar


_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Keith Busch]

On Wed, Mar 31, 2021 at 05:29:46PM +0200, Hannes Reinecke wrote:
> On 3/31/21 4:54 PM, Keith Busch wrote:
> > On Wed, Mar 31, 2021 at 04:15:24PM +0200, Hannes Reinecke wrote:
> > > Hi Keith,
> > > 
> > > On 3/10/21 9:48 PM, Keith Busch wrote:
> > > > On Wed, Mar 03, 2021 at 03:14:02PM -0600, Tony Asleson wrote:
> > > > > 1. There is interest in utilizing the libnvme library for some other
> > > > > projects, when is an official release of the library planned?
> > > > > 
> > > > > 2. Is it planned for nvme-cli to utilize libnvme?
> > > > 
> > > > This is my bad, I fell behind the task due to mutliple conflicts of
> > > > time, but I am back on this right now. The plan is to tag nvme-cli v1.14
> > > > within the next few weeks, then make the shift to libnvme integration
> > > > on a "2.0" version for future work on the master branch. This would
> > > > coincide with an official libnvme stable release.
> > > > 
> > > > I honestly do not have enough devices to regression test all the
> > > > features, so I will continue to maintain nvme-cli 1.x branches as long
> > > > as necessary while ironing out any integration issues.
> > > Any updates here?
> > > We've got some changes/reworks pending (the nvme monitor stuff, and also
> > > a new configuration file mechanism with using a json config file), and
> > > it would be good to know what would be the appropriate base for all of this.
> > > 
> > > We could give you a helping hand in moving nvme-cli over to nvmelib if
> > > that's an issue ...
> > 
> > Thank you, yes, that would be appreciated. I've ported it a couple
> > times, but I keep having to rebase. It's not terribly difficult, but it
> > takes a lot of time..
> > 
> Can you send me your latest attempts?
> That should be a good starting point, and probably avoids some work on our
> side ...

Sorry for the long delay. I thought it was going to be a quick effort to
make that available, but it wasn't so simple. I just popped all the git
stashes I had around and integrated them into a branch I started last
month. The result is here:

  https://github.com/linux-nvme/nvme-cli/tree/libnvme-int-3.4.2021

It's reasonably complete and tests fine for the commands that I can
execute.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Chaitanya Kulkarni]

On 4/7/21 05:46, Padmakar Kalghatgi wrote:
> Along with this, we planned to implement the sideband MI command handling in QEMU.

why ?



_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Chaitanya Kulkarni]

On 4/7/21 05:46, Padmakar Kalghatgi wrote:
>   
> Please share your thougths whether to have this feature as a plugin or as a standalone tool, also provide feedback on our plan to have the sideband MI functionality.

If you want it all in one place you should implement it as plugin,
it will make your life easier.

I think Keith has already NAVKED SMBus, you need to provide a really good
justification if you want that to be a part of nvme-cli.



_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Keith Busch]

On Wed, Apr 07, 2021 at 06:08:06PM +0530, Padmakar Kalghatgi wrote:
> Since most of the companies who develop SSDs, use MI(sideband) channel, we think this will be a good enhancement to the existing functionality which the nvme-cli provides.

Can we even use this from a Linux host? I thought the sideband channel
was typically connected to the baseboard management controller.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Padmakar Kalghatgi]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

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.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Padmakar Kalghatgi]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Wed, Apr 07, 2021 at 11:19:57PM +0000, Chaitanya Kulkarni wrote:
>On 4/7/21 05:46, Padmakar Kalghatgi wrote:
>>
>> Please share your thougths whether to have this feature as a plugin or as a standalone tool, also provide feedback on our plan to have the sideband MI functionality.
>
>If you want it all in one place you should implement it as plugin,
>it will make your life easier.
>
>I think Keith has already NAVKED SMBus, you need to provide a really good
>justification if you want that to be a part of nvme-cli.
>
>
>
There are many SSD Vendors (Eg., as listed earlier) and OEMs using side
band to validate MI. Hence we believe this plugin will be useful to the
community.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Padmakar Kalghatgi]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Thu, Apr 08, 2021 at 08:37:06AM +0900, Keith Busch wrote:
>On Wed, Apr 07, 2021 at 06:08:06PM +0530, Padmakar Kalghatgi wrote:
>> Since most of the companies who develop SSDs, use MI(sideband) channel, we think this will be a good enhancement to the existing functionality which the nvme-cli provides.
>
>Can we even use this from a Linux host? I thought the sideband channel
>was typically connected to the baseboard management controller.
>
Yes, this can be used from Linux host by having additional hardwares, like TotalPhase's aardvark, Corelis etc, which are connected to the NVMe device.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Christoph Hellwig]

On Thu, Apr 08, 2021 at 08:37:06AM +0900, Keith Busch wrote:
> On Wed, Apr 07, 2021 at 06:08:06PM +0530, Padmakar Kalghatgi wrote:
> > Since most of the companies who develop SSDs, use MI(sideband) channel, we think this will be a good enhancement to the existing functionality which the nvme-cli provides.
> 
> Can we even use this from a Linux host? I thought the sideband channel
> was typically connected to the baseboard management controller.

... which typically run Linux these days :)

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Keith Busch]

On Thu, Apr 08, 2021 at 01:21:26PM +0530, Padmakar Kalghatgi wrote:
> On Thu, Apr 08, 2021 at 08:37:06AM +0900, Keith Busch wrote:
> > On Wed, Apr 07, 2021 at 06:08:06PM +0530, Padmakar Kalghatgi wrote:
> > > Since most of the companies who develop SSDs, use MI(sideband) channel, we think this will be a good enhancement to the existing functionality which the nvme-cli provides.
> > 
> > Can we even use this from a Linux host? I thought the sideband channel
> > was typically connected to the baseboard management controller.
> > 
> Yes, this can be used from Linux host by having additional hardwares, like TotalPhase's aardvark, Corelis etc, which are connected to the NVMe device.

That doesn't sound something for end users, but okay. Can we see the
nvme-mi bus driver before considering tools and emulation?

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Chaitanya Kulkarni]

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.



_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Klaus Jensen]

[-- Attachment #1.1: Type: text/plain, Size: 1280 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Padmakar Kalghatgi]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

On Fri, Apr 09, 2021 at 01:46:45AM +0900, Keith Busch wrote:
>On Thu, Apr 08, 2021 at 01:21:26PM +0530, Padmakar Kalghatgi wrote:
>> On Thu, Apr 08, 2021 at 08:37:06AM +0900, Keith Busch wrote:
>> > On Wed, Apr 07, 2021 at 06:08:06PM +0530, Padmakar Kalghatgi wrote:
>> > > Since most of the companies who develop SSDs, use MI(sideband) channel, we think this will be a good enhancement to the existing functionality which the nvme-cli provides.
>> >
>> > Can we even use this from a Linux host? I thought the sideband channel
>> > was typically connected to the baseboard management controller.
>> >
>> Yes, this can be used from Linux host by having additional hardwares, like TotalPhase's aardvark, Corelis etc, which are connected to the NVMe device.
>
>That doesn't sound something for end users, but okay. Can we see the
>nvme-mi bus driver before considering tools and emulation?
>
Please find the below block diagram for the MI communication on the
linux host. The nvme-bus driver is  nothing but the USB driver of the 
hardware which is provided by the vendor.

 ____________________                                                   
|                    |                                                  
|                    |                                                  
|      NVMe-CLI      |             _____________           ____________ 
|     (MI Plugin)    |     USB    |  Aardvark   |  SMBus  |            |
|                    |============|  \Corelis   |=========| NVMe Device|
|                    |            |_____________|         |____________|
|____________________|                                                                     


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: libnvme questions

[Padmakar Kalghatgi]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

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.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme