From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820 Date: Tue, 12 Aug 2014 18:59:19 +0800 Message-ID: <53E9F387.60605@intel.com> References: <1407409371-31728-1-git-send-email-tiejun.chen@intel.com> <1407409371-31728-5-git-send-email-tiejun.chen@intel.com> <53E88482020000780002AFB9@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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" , Jan Beulich Cc: "Zhang, Yang Z" , "xen-devel@lists.xen.org" , "ian.jackson@eu.citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On 2014/8/12 0:00, Tian, Kevin wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Sunday, August 10, 2014 11:53 PM >> >>>>> On 08.08.14 at 23:47, wrote: >>>> From: Chen, Tiejun >>>> Sent: Thursday, August 07, 2014 4:03 AM >>>> >>>> We need to reserve all RMRR mappings in e820 to avoid any >>>> potential guest memory conflict. >>> >>> strictly speaking besides reserving in e820, you should also poke later >>> MMIO BAR allocations to avoid confliction too. Currently it's relative >>> to low_mem_pgend, which is likely to be different from host layout >>> so it's still possible to see a virtual MMIO bar base conflicting to the >>> RMRR ranges which are supposed to be sparse. >> >> Correct. And what's worse: Possible collisions between RMRRs and >> the BIOS we place into the VM need to be taken care of, which may >> turn out rather tricky. >> > > right that becomes tricky. We can provide another hypercall to allow a > VM tell Xen which RMRR can't be assigned due to confliction with gust > BIOS or other hvmloader allocation (if confliction can't be resolved). > > If Xen detects a device owning RMRR is already assigned to the VM, > then fail the hypercall and hvmloader just panic with information to > indicate confliction. > > Otherwise Xen records the information and future dynamic device > assignment like hotplug will be failed if associated RMRR will be in > the confliction list. From my point of view its becoming over complicated. In HVM case, theoretically any devices involving RMRR may be assigned to any given VM. So it may not be necessary to introduce such complex mechanism. Therefore, I think we can reserve all RMRR maps simply in e820, and check if MMIO is overlapping with RMRR for every VM. It should be acceptable. Or please further comments in next revision, I can address your opinion again. Thanks Tiejun > > Thanks > Kevin >