From mboxrd@z Thu Jan 1 00:00:00 1970 From: Haozhong Zhang Subject: Re: [RFC Design Doc] Add vNVDIMM support for Xen Date: Wed, 3 Feb 2016 22:23:22 +0800 Message-ID: <20160203142322.GB22213@hz-desktop.sh.intel.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <56B20A10.70603@citrix.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 Cc: Jun Nakajima , Juergen Gross , Kevin Tian , Wei Liu , Ian Campbell , Stefano Stabellini , George Dunlap , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich , Xiao Guangrong , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 02/03/16 14:09, Andrew Cooper wrote: > On 03/02/16 09:13, Jan Beulich wrote: > >>>> On 03.02.16 at 08:00, wrote: > >> On 02/02/16 17:11, Stefano Stabellini wrote: > >>> Once upon a time somebody made the decision that ACPI tables > >>> on Xen should be static and included in hvmloader. That might have been > >>> a bad decision but at least it was coherent. Loading only *some* tables > >>> from QEMU, but not others, it feels like an incomplete design to me. > >>> > >>> For example, QEMU is currently in charge of emulating the PCI bus, why > >>> shouldn't it be QEMU that generates the PRT and MCFG? > >>> > >> To Keir, Jan and Andrew: > >> > >> Are there anything related to ACPI that must be done (or are better to > >> be done) in hvmloader? > > Some of the static tables (FADT and HPET come to mind) likely would > > better continue to live in hvmloader. MCFG (for example) coming from > > qemu, otoh, would be quite natural (and would finally allow MMCFG > > support for guests in the first place). I.e. ... > > > >>> I prefer switching to QEMU building all ACPI tables for devices that it > >>> is emulating. However this alternative is good too because it is > >>> coherent with the current design. > >> I would prefer to this one if the final conclusion is that only one > >> agent should be allowed to build guest ACPI. As I said above, it looks > >> like a big change to switch to QEMU for all ACPI tables and I'm afraid > >> it would break some existing guests. > > ... I indeed think that tables should come from qemu for components > > living in qemu, and from hvmloader for components coming from Xen. > > 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. > Yes, that is what one of my v1 patches does ([PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu). It extends the existing construct_passthrough_tables() to get the address and size of acpi tables from its parameters (a pair of xenstore keys) rather than the hardcoded ones.