From: Haozhong Zhang <haozhong.zhang@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xensource.com,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Igor Mammedov <imammedo@redhat.com>,
Jan Beulich <jbeulich@suse.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Anthony.Perard@citrix.com, Keir Fraser <keir@xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 2/2] pc-nvdimm acpi: build ACPI tables for pc-nvdimm devices
Date: Tue, 5 Jan 2016 22:01:26 +0800 [thread overview]
Message-ID: <20160105140126.GA29472@hz-desktop.sh.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1601051051010.31111@kaball.uk.xensource.com>
On 01/05/16 11:00, Stefano Stabellini wrote:
> On Mon, 4 Jan 2016, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 04, 2016 at 04:01:08PM +0000, Stefano Stabellini wrote:
> > > CC'ing the Xen tools maintainers and Anthony.
> > >
> > > On Tue, 29 Dec 2015, Haozhong Zhang wrote:
> > > > Reuse existing NVDIMM ACPI code to build ACPI tables for pc-nvdimm
> > > > devices. The resulting tables are then copied into Xen guest domain so
> > > > tha they can be later loaded by Xen hvmloader.
> > > >
> > > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
> > >
> > > How much work would it be to generate the nvdimm acpi tables from the
> > > Xen toolstack?
> >
> > Why duplicate the code? The QEMU generates the NFIT tables and its sub-tables.
> >
> >
> > > Getting the tables from QEMU doesn't seem like a good idea to me, unless
> > > we start getting the whole set of ACPI tables that way.
> >
> > There is also the ACPI DSDT code - which requires an memory region
> > to be reserved for the AML code to drop the parameters so that QEMU
> > can scan the NVDIMM for failures. The region (and size) should be
> > determined by QEMU since it works on this data.
>
> QEMU can generate the whole set of ACPI tables. Why should we take only
> the nvdimm tables and not the others?
>
NVDIMM tables are the only tables required to support vNVDIMM in this
patch series, and they are self-contained and not conflict with other
existing tables built by hvmloader. For other tables built by QEMU, I
have no idea whether they could work with Xen, so I only take nvdimm
tables from QEMU.
> I don't think it is wise to have two components which both think are in
> control of generating ACPI tables, hvmloader (soon to be the toolstack
> with Anthony's work) and QEMU. From an architectural perspective, it
> doesn't look robust to me.
>
Do you mean whenever nvdimm code in QEMU is changed, we would have to
make more efforts to ensure it still works with Xen?
> Could we take this opportunity to switch to QEMU generating the whole
> set of ACPI tables?
>
Not quite sure how much effort would be taken on this change. CCed
hvmloader maintainers for their comments.
Thanks,
Haozhong
next prev parent reply other threads:[~2016-01-05 14:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-29 11:28 [PATCH 0/2] add vNVDIMM support for Xen Haozhong Zhang
2015-12-29 11:28 ` [PATCH 1/2] pc-nvdimm: implement pc-nvdimm device abstract Haozhong Zhang
2015-12-29 11:28 ` [PATCH 2/2] pc-nvdimm acpi: build ACPI tables for pc-nvdimm devices Haozhong Zhang
2016-01-04 16:01 ` Stefano Stabellini
2016-01-04 21:10 ` Konrad Rzeszutek Wilk
2016-01-05 11:00 ` Stefano Stabellini
2016-01-05 14:01 ` Haozhong Zhang [this message]
2016-01-06 14:50 ` Konrad Rzeszutek Wilk
2016-01-06 15:24 ` Haozhong Zhang
2016-01-05 2:14 ` Haozhong Zhang
2015-12-29 15:11 ` [PATCH 0/2] add vNVDIMM support for Xen Xiao Guangrong
2016-01-04 15:57 ` Stefano Stabellini
2016-01-05 1:22 ` Haozhong Zhang
2016-01-04 15:56 ` Stefano Stabellini
2016-01-05 1:33 ` Haozhong Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160105140126.GA29472@hz-desktop.sh.intel.com \
--to=haozhong.zhang@intel.com \
--cc=Anthony.Perard@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ehabkost@redhat.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=imammedo@redhat.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rth@twiddle.net \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.