From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: (v2) Design proposal for RMRR fix Date: Thu, 8 Jan 2015 12:54:51 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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" , "tim@xen.org" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Jan Beulich , "Zhang, Yang Z" , "Chen, Tiejun" List-Id: xen-devel@lists.xenproject.org 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 think it would also fix our long-standing issues with assigning PCI devices to qemu-upstream guests, which up until now have only been worked around. -George