From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: (v2) Design proposal for RMRR fix Date: Thu, 08 Jan 2015 13:00:26 +0000 Message-ID: <54AE8D7A0200007800052A49@mail.emea.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Kevin Tian Cc: "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "tim@xen.org" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Yang Z Zhang , Tiejun Chen List-Id: xen-devel@lists.xenproject.org >>> On 08.01.15 at 13:54, wrote: > On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap > wrote: >> If RMRRs almost always happen up above 2G, for example, then a simple >> solution that wouldn't require too much work would be to make sure >> that the PCI MMIO hole we specify to libxc and to qemu-upstream is big >> enough to include all RMRRs. That would satisfy the libxc and qemu >> requirements. >> >> If we then store specific RMRRs we want included in xenstore, >> hvmloader can put them in the e820 map, and that would satisfy the >> hvmloader requirement. > > An alternate thing to do here would be to "properly" fix the > qemu-upstream problem, by making a way for hvmloader to communicate > changes in the gpfn layout to qemu. > > Then hvmloader could do the work of moving memory under RMRRs to > higher memory; and libxc wouldn't need to be involved at all. I don't think avoiding libxc involvement is possible: Once a certain range of memory has been determined to need reserving (e.g. due to a statically assigned device), attempts to populate the respective GFNs with RAM would (ought to) fail. Jan