From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: (v2) Design proposal for RMRR fix Date: Fri, 16 Jan 2015 12:17:50 -0500 Message-ID: <20150116171750.GI11402@l.oracle.com> References: <54B3AE8802000078000539B7@mail.emea.novell.com> <20150113164546.GF28074@localhost.localdomain> <20150114204245.GB12738@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tian, Kevin" Cc: "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , George Dunlap , "ian.jackson@eu.citrix.com" , "tim@xen.org" , "xen-devel@lists.xen.org" , Jan Beulich , "Zhang, Yang Z" , "Chen, Tiejun" List-Id: xen-devel@lists.xenproject.org On Thu, Jan 15, 2015 at 08:09:34AM +0000, Tian, Kevin wrote: > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > Sent: Thursday, January 15, 2015 4:43 AM > > > > On Wed, Jan 14, 2015 at 08:13:14AM +0000, Tian, Kevin wrote: > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > > > Sent: Wednesday, January 14, 2015 12:46 AM > > > > > > > > > > > > Perhaps an easier way of this is to use the existing > > > > mechanism we have - that is the XENMEM_memory_map (which > > > > BTW e820_host uses). If all of this is done in the libxl (which > > > > already does this based on the host E820, thought it can > > > > be modified to query the hypervisor for other 'reserved > > > > regions') and hvmloader is modified to use XENMEM_memory_map > > > > and base its E820 on that (and also QEMU-xen), then we solve > > > > this problem and also the http://bugs.xenproject.org/xen/bug/28? > > > > > > > > > > I'm not familiar with that option, but a quick search looks saying > > > it's only for PV guest? > > > > It was originally for PV, but the hypercall can be executed under > > HVM now too (thanks for PVH patches). > > > > > > and please note XENMEM_memory_map only includes RAM entries > > > (looks also only for pv), while following above intention what we > > > really want is real e820_host w/ all entries filled. > > > > It includeds whatever we want to put in there. It can have > > RAM, RSV, etc. That is what e820_host does for PV guests - it fills > > it out with an E820 that looks like the real thing. > > > > Thanks for help me understand the status. So if we want to use this > interface, the major work would be in the caller (e.g. hvmloader) > to favor that layout. Right, and it would also help in other situations (such as when doing PCI passthrough in HVM guests with some inflexible PCIe devices that really want an 1-1 BAR mapping - which this would help with). > > Kevin