From mboxrd@z Thu Jan  1 00:00:00 1970
From: Haozhong Zhang <haozhong.zhang@intel.com>
Subject: Re: [PATCH 4/4] hvmloader: add support to load extra
 ACPI tables from qemu
Date: Fri, 22 Jan 2016 10:43:29 +0800
Message-ID: <20160122024329.GC6362@hz-desktop.sh.intel.com>
References: <569FA7F3.8080506@linux.intel.com>
	<569FCCED02000078000C94BA@prv-mh.provo.novell.com>
	<569FC112.9060309@linux.intel.com>
	<56A0A25002000078000C971B@prv-mh.provo.novell.com>
	<56A095E3.5060507@linux.intel.com>
	<56A0AA8A02000078000C977D@prv-mh.provo.novell.com>
	<56A0A09A.2050101@linux.intel.com>
	<56A0C02A02000078000C9823@prv-mh.provo.novell.com>
	<20160121140103.GB6362@hz-desktop.sh.intel.com>
	<56A0FEA102000078000C9A44@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <56A0FEA102000078000C9A44@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org, Jun Nakajima <jun.nakajima@intel.com>, Xiao Guangrong <guangrong.xiao@linux.intel.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 01/21/16 07:52, Jan Beulich wrote:
> >>> On 21.01.16 at 15:01, <haozhong.zhang@intel.com> wrote:
> > On 01/21/16 03:25, Jan Beulich wrote:
> >> >>> On 21.01.16 at 10:10, <guangrong.xiao@linux.intel.com> wrote:
> >> > b) some _DSMs control PMEM so you should filter out these kind of _DSMs and
> >> >     handle them in hypervisor.
> >> 
> >> Not if (see above) following the model we currently have in place.
> >>
> > 
> > You mean let dom0 linux evaluates those _DSMs and interact with
> > hypervisor if necessary (e.g. XENPF_mem_hotadd for memory hotplug)?
> 
> Yes.
> 
> >> > c) hypervisor should mange PMEM resource pool and partition it to multiple
> >> >     VMs.
> >> 
> >> Yes.
> >>
> > 
> > But I Still do not quite understand this part: why must pmem resource
> > management and partition be done in hypervisor?
> 
> Because that's where memory management belongs. And PMEM,
> other than PBLK, is just another form of RAM.
> 
> > I mean if we allow the following steps of operations (for example)
> > (1) partition pmem in dom 0
> > (2) get address and size of each partition (part_addr, part_size)
> > (3) call a hypercall like nvdimm_memory_mapping(d, part_addr, part_size, 
> > gpfn) to
> >     map a partition to the address gpfn in dom d.
> > Only the last step requires hypervisor. Would anything be wrong if we
> > allow above operations?
> 
> The main issue is that this would imo be a layering violation. I'm
> sure it can be made work, but that doesn't mean that's the way
> it ought to work.
> 
> Jan
> 

OK, then it makes sense to put them in hypervisor. I'll think about
this and note in the design document.

Thanks,
Haozhong