From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu Date: Wed, 20 Jan 2016 01:46:01 -0700 Message-ID: <569F575902000078000C8EDC@prv-mh.provo.novell.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160120053132.GA5005@hz-desktop.sh.intel.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Haozhong Zhang Cc: 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 20.01.16 at 06:31, wrote: > The primary reason of current solution is to reuse existing NVDIMM > driver in Linux kernel. Re-using code in the Dom0 kernel has benefits and drawbacks, and in any event needs to depend on proper layering to remain in place. A benefit is less code duplication between Xen and Linux; along the same lines a drawback is code duplication between various Dom0 OS variants. > One responsibility of this driver is to discover NVDIMM devices and > their parameters (e.g. which portion of an NVDIMM device can be mapped > into the system address space and which address it is mapped to) by > parsing ACPI NFIT tables. Looking at the NFIT spec in Sec 5.2.25 of > ACPI Specification v6 and the actual code in Linux kernel > (drivers/acpi/nfit.*), it's not a trivial task. To answer one of Kevin's questions: The NFIT table doesn't appear to require the ACPI interpreter. They seem more like SRAT and SLIT. Also you failed to answer Kevin's question regarding E820 entries: I think NVDIMM (or at least parts thereof) get represented in E820 (or the EFI memory map), and if that's the case this would be a very strong hint towards management needing to be in the hypervisor. > Secondly, the driver implements a convenient block device interface to > let software access areas where NVDIMM devices are mapped. The > existing vNVDIMM implementation in QEMU uses this interface. > > As Linux NVDIMM driver has already done above, why do we bother to > reimplement them in Xen? See above; a possibility is that we may need a split model (block layer parts on Dom0, "normal memory" parts in the hypervisor. Iirc the split is being determined by firmware, and hence set in stone by the time OS (or hypervisor) boot starts. Jan