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 20:49:38 +0800 Message-ID: <20160203124938.GA22213@hz-desktop.sh.intel.com> References: <20160201054414.GA25211@hz-desktop.sh.intel.com> <20160202191519.GB21656@char.us.oracle.com> <20160203082831.GB4248@hz-desktop.sh.intel.com> <56B1D3FE02000078000CDD92@prv-mh.provo.novell.com> <20160203122220.GA15605@hz-desktop.sh.intel.com> <56B202C102000078000CE01D@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <56B202C102000078000CE01D@prv-mh.provo.novell.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: Jan Beulich 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 02/03/16 05:38, Jan Beulich wrote: > >>> On 03.02.16 at 13:22, wrote: > > On 02/03/16 02:18, Jan Beulich wrote: > >> >>> On 03.02.16 at 09:28, wrote: > >> > On 02/02/16 14:15, Konrad Rzeszutek Wilk wrote: > >> >> > 3.1 Guest clwb/clflushopt/pcommit Enabling > >> >> > > >> >> > The instruction enabling is simple and we do the same work as in > > KVM/QEMU. > >> >> > - All three instructions are exposed to guest via guest cpuid. > >> >> > - L1 guest pcommit is never intercepted by Xen. > >> >> > >> >> I wish there was some watermarks like the PLE has. > >> >> > >> >> My fear is that an unfriendly guest can issue sfence all day long > >> >> flushing out other guests MMC queue (the writes followed by pcommits). > >> >> Which means that an guest may have degraded performance as their > >> >> memory writes are being flushed out immediately as if they were > >> >> being written to UC instead of WB memory. > >> > > >> > pcommit takes no parameter and it seems hard to solve this problem > >> > from hardware for now. And the current VMX does not provide mechanism > >> > to limit the commit rate of pcommit like PLE for pause. > >> > > >> >> In other words - the NVDIMM resource does not provide any resource > >> >> isolation. However this may not be any different than what we had > >> >> nowadays with CPU caches. > >> >> > >> > > >> > Does Xen have any mechanism to isolate multiple guests' operations on > >> > CPU caches? > >> > >> No. All it does is disallow wbinvd for guests not controlling any > >> actual hardware. Perhaps pcommit should at least be limited in > >> a similar way? > >> > > > > But pcommit is a must that makes writes be persistent on pmem. I'll > > look at how guest wbinvd is limited in Xen. > > But we could intercept it on guests _not_ supposed to use it, in order > to simply drop in on the floor. > Oh yes! We can drop pcommit from domains not having access to host NVDIMM, just like vmx_wbinvd_intercept() dropping wbinvd from domains not accessing host iomem and ioport. > > Any functions suggested, vmx_wbinvd_intercept()? > > A good example, yes. > > Jan > Thanks, Haozhong