From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [RFC Design Doc] Add vNVDIMM support for Xen Date: Wed, 24 Feb 2016 09:54:19 -0700 Message-ID: <56CDEE4B02000078000D5DAD@prv-mh.provo.novell.com> References: <20160201054414.GA25211@hz-desktop.sh.intel.com> <56C60AB102000078000D3D22@prv-mh.provo.novell.com> <20160224132855.GA2627@hz-desktop.sh.intel.com> <56CDCB1702000078000D5B6C@prv-mh.provo.novell.com> <20160224154833.GB10229@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: <20160224154833.GB10229@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: Juergen Gross , Kevin Tian , Wei Liu , Ian Campbell , Stefano Stabellini , George Dunlap , Andrew Cooper , Ian Jackson , xen-devel@lists.xen.org, Jun Nakajima , Xiao Guangrong , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 24.02.16 at 16:48, wrote: > On 02/24/16 07:24, Jan Beulich wrote: >> >>> On 24.02.16 at 14:28, wrote: >> > On 02/18/16 10:17, Jan Beulich wrote: >> >> >>> On 01.02.16 at 06:44, wrote: >> >> > 3.3 Guest ACPI Emulation >> >> > >> >> > 3.3.1 My Design >> >> > >> >> > Guest ACPI emulation is composed of two parts: building guest NFIT >> >> > and SSDT that defines ACPI namespace devices for NVDIMM, and >> >> > emulating guest _DSM. >> >> > >> >> > (1) Building Guest ACPI Tables >> >> > >> >> > This design reuses and extends hvmloader's existing mechanism that >> >> > loads passthrough ACPI tables from binary files to load NFIT and >> >> > SSDT tables built by QEMU: >> >> > 1) Because the current QEMU does not building any ACPI tables when >> >> > it runs as the Xen device model, this design needs to patch QEMU >> >> > to build NFIT and SSDT (so far only NFIT and SSDT) in this case. >> >> > >> >> > 2) QEMU copies NFIT and SSDT to the end of guest memory below >> >> > 4G. The guest address and size of those tables are written into >> >> > xenstore (/local/domain/domid/hvmloader/dm-acpi/{address,length}). >> >> > >> >> > 3) hvmloader is patched to probe and load device model passthrough >> >> > ACPI tables from above xenstore keys. The detected ACPI tables >> >> > are then appended to the end of existing guest ACPI tables just >> >> > like what current construct_passthrough_tables() does. >> >> > >> >> > Reasons for this design are listed below: >> >> > - NFIT and SSDT in question are quite self-contained, i.e. they do >> >> > not refer to other ACPI tables and not conflict with existing >> >> > guest ACPI tables in Xen. Therefore, it is safe to copy them from >> >> > QEMU and append to existing guest ACPI tables. >> >> >> >> How is this not conflicting being guaranteed? In particular I don't >> >> see how tables containing AML code and coming from different >> >> sources won't possibly cause ACPI name space collisions. >> >> >> > >> > Really there is no effective mechanism to avoid ACPI name space >> > collisions (and other kinds of conflicts) between ACPI tables loaded >> > from QEMU and ACPI tables built by hvmloader. Because which ACPI tables >> > are loaded is determined by developers, IMO it's developers' >> > responsibility to avoid any collisions and conflicts with existing ACPI >> > tables. >> >> Right, but this needs to be spelled out and settled on at design >> time (i.e. now), rather leaving things unspecified, awaiting the >> first clash. > > So that means if no collision-proof mechanism is introduced, Xen should not > trust any passed-in ACPI tables and should build them by itself? Basically yes, albeit collision-proof may be too much to demand. Simply separating name spaces (for hvmloader and qemu to have their own sub-spaces) would be sufficient imo. We should trust ourselves to play by such a specification. Jan