Re: [PATCH 2/2] NVDIMM: Init vNVDIMM's LSA index block if it hasn't been

[Robert Hoo <robert.hu@linux.intel.com>]

On Thu, 2022-03-31 at 16:41 +0200, Igor Mammedov wrote:
> On Thu, 31 Mar 2022 21:08:12 +0800
> Robert Hoo <robert.hu@linux.intel.com> wrote:
>  
> > > 
> > > Can user initialize/format LSA from guest using ndctl/some other
> > > tool?
> > >   
> > 
> > Yes, he can. But when guest Kernel already told him this is a dimm
> > without label capability, dare/should he take this dangerous
> > action?;-)
> 
> I don't think this feature belongs to QEMU (i.e. hw emulation).
> It's task that is usually accomplished by firmware or OS
> (in context of QEMU its guest's responsibility).
> 

Thanks Igor.
Actually before I compose this patch, I was pondering on this as well:
whose obligation to fulfill this function, i.e. initialize the LSA.

So I asked around (and still asking), knowing these about native usage,
(correct me if I'm wrong), which we virtualization should mimic in
principle:

a) before user start to use NVDIMM, he's supposed to ipmctl[0] create
goal firstly, to determine 2LM mode or app direct mode, which usually
initializes the LSA. So user doesn't necessarily to explicit 'ndctl
init-label' although he can do this to init LSA again.

b) I heard that, perhaps, even when DIMMs are sent out from factory, it
has LSA initialized (not quite certain about this, I'm still
confirming).

What specs say
---
In NVDIMM Namespace spec[1], Chap 2 "Namespaces": 
"NVDIMM vendors define the size of their label storage area and,
therefor, the number of labels it holds."

I think: In QEMU context, it's QEMU who's the vNVDIMM's vendor.

In UEFI spec [2], "13.19 NVDIMM Label Protocol", page 640:
"Before Index Blocks and labels can be utilized, the software managing
the Label Storage Area must determine the total number of labels that
will be supported and utilizing the description above, calculate the
size of the Index Blocks required."

I think: In QEMU context, it's QEMU who emulates LSA and therefore the
management software of it.

What's real limitation on QEMU vNVDIMM implementation
---
In VM:
ipmctl isn't supported.
Only app direct mode is supported. (i.e. no bother to ipmctl create
goal first).
vNVDIMM is actually presented to user in a ready-to-use initial state.
We never tell user you must 'ndctl init-label' then can use it.
Nor tell user that you should 'ipmctl create-goal' first, because in
fact ipmctl isn't available at all.


That's all the story and thoughts before I compose this patch:)

[0] https://docs.pmem.io/ipmctl-user-guide/ (and, ipmctl is for Intel
Optane PMEM only)
[1] https://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
[2] 
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf

> 
> PS:
> It's true that QEMU caries some 'firmware' code, like composing
> ACPI tables but we do it only to reduce QEMU<->firmware ABI
> necessary for hardware description and that's pretty much it.
> Unfortunately this series doesn't fit the bill.
> 
Yeah, I've seen this part of code, but a little difficult to comprehend
them, especially for me a stranger to ACPI. Where can I find related
design document?
I now only find a valuable doc: docs/specs/acpi_nvdimm.rst.
>