From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT Date: Tue, 30 Sep 2014 08:07:28 +0100 Message-ID: <542A72D0020000780003AD60@mail.emea.novell.com> References: <541FB087.4080008@intel.com> <541FB7C3.9080608@intel.com> <541FFFC50200007800036C28@mail.emea.novell.com> <541FE65A.8070803@intel.com> <542017E80200007800036D1E@mail.emea.novell.com> <5420D357.1060202@intel.com> <5422823B.1090109@intel.com> <5422A1250200007800038152@mail.emea.novell.com> <54228683.1090103@intel.com> <5422A74C02000078000381B0@mail.emea.novell.com> <5423EA510200007800038C2C@mail.emea.novell.com> <542526010200007800039677@mail.emea.novell.com> 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: Tiejun Chen , Yang Z Zhang Cc: Kevin Tian , Tim Deegan , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>> On 30.09.14 at 05:49, wrote: > Jan Beulich wrote on 2014-09-26: >>>>> On 26.09.14 at 03:24, wrote: >>> Jan Beulich wrote on 2014-09-25: >>>>>>> On 25.09.14 at 04:30, wrote: >>>>> How do the checking in P2M updates? Only hvmloader knows whether >>>>> the RMRR region is reserved. If we want do the check in >>>>> hypervisor, we need to report those info to hypervisor. >>>> >>>> First of all the hypervisor has the information - it is where the >>>> information comes from that tools and hvmloader consume. And then >>>> the check will need to be a collision check: If while establishing >>>> an identity mapping another mapping is found to be already in >>>> place, the request will need to be failed. And similarly if a >>>> "normal" mapping request finds a 1:1 mapping already in place, this >>>> ought to result in failure too. Of course a prerequisite to this is >>>> that error get properly >>> bubbled up through all layers. >>> >>> If there is another mapping already there and it is different from >>> the one we are establishing, we should return failure. But if the >>> existing mapping is same to the one we are establishing, how we can >>> know whether it is a 'normal memory 1:1' mapping or it is created by >>> previous operation of RMRR creating(e.g. there already a device with >>> RMRR assigned to this guest). What I am thinking is that we need a >>> flag to know whether the mapping is RMRR mapping or regular memory >> mapping. >> >> If the new and old mappings are the same, nothing needs to be done at >> all (as is already the case in one direction in the patches we have >> seen). And yes, for the case when there is an occasional 1:1 mapping >> we of course will need some way of identifying intentional ones. > > So how about adding a new p2m type to do this? It may also helpful when > creating a guest without device attached.(I mentioned it in another thread). If that makes it easier to implement - why not? But I think you're aware that raising memory management related questions without Tim in the loop isn't going to yield a result you can reasonably rely on later being accepted in patch form. Jan