From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu Date: Thu, 21 Jan 2016 01:17:06 +0800 Message-ID: <569FC112.9060309@linux.intel.com> References: <1451388711-18646-1-git-send-email-haozhong.zhang@intel.com> <1451388711-18646-5-git-send-email-haozhong.zhang@intel.com> <5699362402000078000C7803@prv-mh.provo.novell.com> <20160118005255.GC3528@hz-desktop.sh.intel.com> <569CB47502000078000C7CFB@prv-mh.provo.novell.com> <20160120053132.GA5005@hz-desktop.sh.intel.com> <569F575902000078000C8EDC@prv-mh.provo.novell.com> <20160120110449.GD4939@hz-desktop.sh.intel.com> <569F7B8302000078000C8FF8@prv-mh.provo.novell.com> <569FA7F3.8080506@linux.intel.com> <569FCCED02000078000C94BA@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <569FCCED02000078000C94BA@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Haozhong Zhang , Kevin Tian , Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , xen-devel@lists.xen.org, Jun Nakajima , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 01/21/2016 01:07 AM, Jan Beulich wrote: >>>> On 20.01.16 at 16:29, wrote: >> On 01/20/2016 07:20 PM, Jan Beulich wrote: >>> To answer this I need to have my understanding of the partitioning >>> being done by firmware confirmed: If that's the case, then "normal" >>> means the part that doesn't get exposed as a block device (SSD). >>> In any event there's no correlation to guest exposure here. >> >> Firmware does not manage NVDIMM. All the operations of nvdimm are handled >> by OS. >> >> Actually, there are lots of things we should take into account if we move >> the NVDIMM management to hypervisor: >> a) ACPI NFIT interpretation >> A new ACPI table introduced in ACPI 6.0 is named NFIT which exports the >> base information of NVDIMM devices which includes PMEM info, PBLK >> info, nvdimm device interleave, vendor info, etc. Let me explain it one >> by one. >> >> PMEM and PBLK are two modes to access NVDIMM devices: >> 1) PMEM can be treated as NV-RAM which is directly mapped to CPU's address >> space so that CPU can r/w it directly. >> 2) as NVDIMM has huge capability and CPU's address space is limited, NVDIMM >> only offers two windows which are mapped to CPU's address space, the data >> window and access window, so that CPU can use these two windows to access >> the whole NVDIMM device. > > You fail to mention PBLK. The question above really was about what The 2) is PBLK. > entity controls which of the two modes get used (and perhaps for > which parts of the overall NVDIMM). So i think the "normal" you mentioned is about PMEM. :)