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

[Igor Mammedov]

On Fri, 01 Apr 2022 12:07:56 +0800
Robert Hoo <robert.hu@linux.intel.com> wrote:

> 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).
if you find a NVDIMM that implements initialization in hardware,
then it could be considered. But QEMU isn't a factory, it's rather
a component within factory that perform specific task while other
components manage it (including storage it consumes, see libguestfs
project which is similar to what you are trying to do, but deals
with conventional storage).

> 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."
one does define size and lsa size on QEMU command line,
how it will be consumed is the business of firmware/operating system
that runs within VM though.

> 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.

ipmictl isn't hardware, it's tool to connect to firmware
running on BMC. In virt world it corresponds to guest code running
within VM or some mgmt app outside QEMU that can implement IPMI
interface. You can try to generalize this utility and extend EDKII
to support it, which would benefit not only QEMU but other
consumers of EDKII.
wrt IPMI, I'm not familiar with BMC support in QEMU, but looks
there are at least some (see hw/ipmi folder) implementations.

As for [b] point, QEMU is not software managing NVDIMM, it's
hardware emulator. Duplicating irrelevant features in QEMU
will just bloat it and make project unmanageable.
Point [b] to me looks more like a separate utility that could
initialize vNVDIMM for further consumption (I'd ask libguestfs
or ndctl folks if they would like to add support for 'out of band'
vNVDIMM management, but likely outcome to this would be what
libguestfs is doing currently with disks, start VM appliance
and run ndctl within it to initialize vNVDIMM).
 
> 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.
> >   
>