qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 2/3] spapr: Add NVDIMM device support


From: Bharata B Rao
Subject: Re: [PATCH v3 2/3] spapr: Add NVDIMM device support
Date: Wed, 27 Nov 2019 09:50:54 +0530

On Fri, Nov 22, 2019 at 10:42 AM David Gibson
<address@hidden> wrote:
>
> Ok.  A number of queries about this.
>
> 1) The PAPR spec for ibm,dynamic-memory-v2 says that the first word in
> each entry is the number of LMBs, but for NVDIMMs you use the
> not-necessarily-equal scm_block_size instead.  Does the NVDIMM
> amendment for PAPR really specify to use different block sizes for
> these cases?  (In which case that's a really stupid spec decision, but
> that wouldn't surprise me at this point).

SCM block sizes can be different from LMB sizes, but here we enforce
that SCM device size (excluding metadata) to multiple of LMB size so
that we don't end up memory range that is not aligned to LMB size.

>
> 2) Similarly, the ibm,dynamic-memory-v2 description says that the
> memory block described by the entry has a whole batch of contiguous
> DRCs starting at the DRC index given and continuing for #LMBs DRCs.
> For NVDIMMs it appears that you just have one DRC for the whole
> NVDIMM.  Is that right?

One NVDIMM has one DRC, In our case, we need to mark the LMBs
corresponding to that address range in ibm,dynamic-memory-v2 as
reserved and invalid.

>
> 3) You're not setting *any* extra flags on the entry.  How is the
> guest supposed to know which are NVDIMM entries and which are regular
> DIMM entries?  AFAICT in this version the NVDIMM slots are
> indistinguishable from the unassigned hotplug memory (which makes the
> difference in LMB and DRC numbering even more troubling).

For NVDIMM case, this patch should populate the LMB set in
ibm,dynamic-memory-v2 something like below:
            elem = spapr_get_drconf_cell(size /lmb_size, addr,
                                         0, -1,
SPAPR_LMB_FLAGS_RESERVED | SPAPR_LMB_FLAGS_DRC_INVALID);

This will ensure that the NVDIMM range will never be considered as
valid memory range for memory hotplug.

>
> 4) AFAICT these are _present_ NVDIMMs, so why is
> SPAPR_LMB_FLAGS_ASSIGNED not set for them?  (and why is the node
> forced to -1, regardless of di->node).
>
> >          QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
> >          nr_entries++;
> >          cur_addr = addr + size;
> > @@ -1261,6 +1273,85 @@ static void spapr_dt_hypervisor(SpaprMachineState 
> > *spapr, void *fdt)
> >      }
> >  }
> >

> > +static void spapr_create_nvdimm_dr_connectors(SpaprMachineState *spapr)
> > +{
> > +    MachineState *machine = MACHINE(spapr);
> > +    int i;
> > +
> > +    for (i = 0; i < machine->ram_slots; i++) {
> > +        spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_PMEM, i);
>
> What happens if you try to plug an NVDIMM to one of these slots, but a
> regular DIMM has already taken it?

NVDIMM hotplug won't get that occupied slot.

Regards,
Bharata.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]