From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Peng Subject: Re: [RFC XEN PATCH v3 00/39] Add vNVDIMM support to HVM domains Date: Fri, 27 Oct 2017 11:26:19 +0800 Message-ID: <1509074779.3110.17.camel@linux.intel.com> References: <20170911043820.14617-1-haozhong.zhang@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7940436864206561521==" Return-path: In-Reply-To: <20170911043820.14617-1-haozhong.zhang@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Haozhong Zhang , xen-devel@lists.xen.org Cc: Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Jan Beulich , Dan Williams List-Id: xen-devel@lists.xenproject.org --===============7940436864206561521== Content-Type: multipart/alternative; boundary="=-TV+zu3QEMeZuODCg8L/9" --=-TV+zu3QEMeZuODCg8L/9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote: > Overview > ================== > > > (RFC v2 can be found at https://lists.xen.org/archives/html/xen- devel/2017-03/msg02401.html) > > Well, this RFC v3 changes and inflates a lot from previous versions. > The primary changes are listed below, most of which are to simplify > the first implementation and avoid additional inflation. > > 1. Drop the support to maintain the frametable and M2P table of PMEM > in RAM. In the future, we may add this support back. I don't find any discussion in v2 about this, but I'm thinking putting those Xen data structures in RAM sometimes is useful (e.g. when performance is important). It's better not making hard restriction on this. > > 2. Hide host NFIT and deny access to host PMEM from Dom0. In other > words, the kernel NVDIMM driver is loaded in Dom 0 and existing > management utilities (e.g. ndctl) do not work in Dom0 anymore. This > is to workaround the inferences of PMEM access between Dom0 and Xen > hypervisor. In the future, we may add a stub driver in Dom0 which > will hold the PMEM pages being used by Xen hypervisor and/or other > domains. > > 3. As there is no NVDIMM driver and management utilities in Dom0 now, > > we cannot easily specify an area of host NVDIMM (e.g., by /dev/pmem0) > and manage NVDIMM in Dom0 (e.g., creating labels). Instead, we > have to specify the exact MFNs of host PMEM pages in xl domain > configuration files and the newly added Xen NVDIMM management > utility xen-ndctl. > > If there are indeed some tasks that have to be handled by existing > driver and management utilities, such as recovery from hardware > failures, they have to be accomplished out of Xen environment. What kind of recovery can happen and does the recovery can happen at runtime? For example, can we recover a portion of NVDIMM assigned to a certain VM while keep other VMs still using NVDIMM? > > After 2. is solved in the future, we would be able to make existing > driver and management utilities work in Dom0 again. Is there any reason why we can't do it now? If existing ndctl (with additional patches) can work then we don't need introduce xen-ndctl anymore? I think that keeps user interface clearer. Chao --=-TV+zu3QEMeZuODCg8L/9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

On Mon, 2017-09-11 at 12:37 +0800, Haozhong Z= hang wrote:

Overview
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(= RFC v2 can be found at https://lists.xen.org/archives/html/xen-devel/2017-0= 3/msg02401.html)

Well, this RFC v3 changes and inf= lates a lot from previous versions.
The primary changes are liste= d below, most of which are to simplify
the first implementation a= nd avoid additional inflation.

1. Drop the support= to maintain the frametable and M2P table of PMEM
&nb= sp;in RAM. In the future, we may add this support back.

<= div>

I don't find any discussion in v2 about this, but I'm th= inking putting those Xen data structures in RAM sometimes is useful (e.g. w= hen performance is important). It's better not making hard restriction on t= his.

2. H= ide host NFIT and deny access to host PMEM from Dom0. In other
&n= bsp;  words, the kernel NVDIMM driver is loaded in Dom 0 and exis= ting
   management utilities (e.g. ndctl) do not w= ork in Dom0 anymore. This
   is to workaround the = inferences of PMEM access between Dom0 and Xen
   = hypervisor. In the future, we may add a stub driver in Dom0 which
   will hold the PMEM pages being used by Xen hypervisor an= d/or other
   domains.

3. As there is no NVDIMM driver and management utilities in Dom0 now,
   we cannot easily specify an area of host NVDIMM (e= .g., by /dev/pmem0)
   and manage NVDIMM in Dom0 (= e.g., creating labels).  Instead, we
   = have to specify the exact MFNs of host PMEM pages in xl domain
&n= bsp;  configuration files and the newly added Xen NVDIMM manageme= nt
   utility xen-ndctl.

=    If there are indeed some tasks that have to be handled by= existing
   driver and management utilities, such= as recovery from hardware
   failures, they have = to be accomplished out of Xen environment.

What kind of recovery can happen and does the recovery can happen at = runtime? For example, can we recover a portion of NVDIMM assigned to a cert= ain VM while keep other VMs still using NVDIMM?

After 2. is solved= in the future, we would be able to make existing

&nb= sp;driver and management utilities work in Dom0 again.

Is there any reason why we can't do it now? If existing n= dctl (with additional patches) can work then we don't need introduce xen-nd= ctl anymore? I think that keeps user interface clearer.

Chao

--=-TV+zu3QEMeZuODCg8L/9-- --===============7940436864206561521== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7940436864206561521==--