Re: [Xen-devel] [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Jan 26, 2016 at 4:34 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 26.01.16 at 16:57, <haozhong.zhang@xxxxxxxxx> wrote:
>> On 01/26/16 08:37, Jan Beulich wrote:
>>> >>> On 26.01.16 at 15:44, <konrad.wilk@xxxxxxxxxx> wrote:
>>> >>  Last year at Linux Plumbers Conference I attended a session dedicated
>>> >> to NVDIMM support. I asked the very same question and the INTEL guy
>>> >> there told me there is indeed something like a partition table meant
>>> >> to describe the layout of the memory areas and their contents.
>>> >
>>> > It is described in details at pmem.io, look at  Documents, see
>>> > http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf see Namespaces section.
>>>
>>> Well, that's about how PMEM and PBLK ranges get marked, but not
>>> about how use of the space inside a PMEM range is coordinated.
>>>
>>
>> How a NVDIMM is partitioned into pmem and pblk is described by ACPI NFIT
>> table.
>> Namespace to pmem is something like partition table to disk.
>
> But I'm talking about sub-dividing the space inside an individual
> PMEM range.

Well as long as at a high level full PMEM blocks can be allocated /
marked to a single OS, then that OS can figure out if / how to further
subdivide them (and store information about that subdivision).

But in any case, since it seems from what Haozhong and Konrad say,
that the point of this *is* in fact to take advantage of the
persistence, then it seems like allowing Linux to solve the problem of
how to subdivide PMEM blocks and just leveraging their solution would
be better than trying to duplicate all that effort inside of Xen.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel