From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Philipson Subject: Re: [RFC Design Doc] Add vNVDIMM support for Xen Date: Sat, 6 Feb 2016 11:17:44 -0500 Message-ID: <56B61CA8.3000401@gmail.com> References: <20160201054414.GA25211@hz-desktop.sh.intel.com> <20160203070052.GA4248@hz-desktop.sh.intel.com> <56B1D2CB02000078000CDD82@prv-mh.provo.novell.com> <56B20A10.70603@citrix.com> <56B4B462.1090005@gmail.com> <20160206014301.GB4074@hz-desktop.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20160206014301.GB4074@hz-desktop.sh.intel.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: Andrew Cooper , Jan Beulich , Juergen Gross , Kevin Tian , Wei Liu , Ian Campbell , Stefano Stabellini , George Dunlap , Ian Jackson , xen-devel@lists.xen.org, Jun Nakajima , Xiao Guangrong , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 02/05/2016 08:43 PM, Haozhong Zhang wrote: > On 02/05/16 09:40, Ross Philipson wrote: >> On 02/03/2016 09:09 AM, Andrew Cooper wrote: > [...] >>> I agree. >>> >>> There has to be a single entity responsible for collating the eventual >>> ACPI handed to the guest, and this is definitely HVMLoader. >>> >>> However, it is correct that Qemu create the ACPI tables for the devices >>> it emulates for the guest. >>> >>> We need to agree on a mechanism whereby each entity can provide their >>> own subset of the ACPI tables to HVMLoader, and have HVMLoader present >>> the final set properly to the VM. >>> >>> There is an existing usecase of passing the Host SLIC table to a VM, for >>> OEM Versions of Windows. I believe this is achieved with >>> HVM_XS_ACPI_PT_{ADDRESS,LENGTH}, but that mechanism is a little >>> inflexible and could probably do with being made a little more generic. >> >> A while back I added a generic mechanism to load extra ACPI tables into a >> guest, configurable at runtime. It looks like the functionality is still >> present. That might be an option. >> >> Also, following the thread, it wasn't clear if some of the tables like t= he >> SSDT for the NVDIMM device and it's _FIT/_DSM methods were something that >> could be statically created at build time. If it is something that needs= to >> be generated at runtime (e.g. platform specific), I have a library that = can >> generate any AML on the fly and create SSDTs. >> >> Anyway just FYI in case this is helpful. >> > = > Hi Ross, > = > Thanks for the information! > = > SSDT for NVDIMM devices can not be created statically, because the > number of some items in it can not be determined at build time. For > example, the number of NVDIMM ACPI namespace devices (_DSM is under it) > defined in SSDT is determined by the number of vNVDIMM devices in domain > configuration. FYI, a sample SSDT for NVDIMM looks like > = > Scope (\_SB){ > Device (NVDR) // NVDIMM Root device > { > Name (_HID, =93ACPI0012=94) > Method (_STA) {...} > Method (_FIT) {...} > Method (_DSM, ...) { > ... > } > } > = > Device (NVD0) // 1st NVDIMM Device > { > Name(_ADR, h0) > Method (_DSM, ...) { > ... > } > } > = > Device (NVD1) // 2nd NVDIMM Device > { > Name(_ADR, h1) > Method (_DSM, ...) { > ... > } > } > = > ... > } Makes sense. > = > I had ported QEMU's AML builder code as well as NVDIMM ACPI building > code to hvmloader and it did work, but then there was too much > duplicated code for vNVDIMM between QEMU and hvmloader for vNVDIMM. > Therefore, I prefer to let QEMU that emulates vNVDIMM devices > to build those tables, as in Andrew and Jan's replies. Yea it looks like QEUM's AML generating code is quite complete nowadays. Back when I wrote my library there wasn't really much out there. Anyway this is where it is if there is something that I might generate that is missing: https://github.com/OpenXT/xctools/tree/master/libxenacpi > = > Thanks, > Haozhong > = -- = Ross Philipson