From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT Date: Thu, 2 Oct 2014 12:29:37 +0200 Message-ID: <20141002102937.GD43394@deinos.phlegethon.org> References: <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> <542A72D0020000780003AD60@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <542A72D0020000780003AD60@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Yang Z Zhang , Tiejun Chen , Kevin Tian , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 08:07 +0100 on 30 Sep (1412060848), Jan Beulich wrote: > >>> 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. Although adding new p2m types is generally OK, I'm not sure I see the need here. The useful cases are trivial: - gfn space unoccupied -> insert mapping; success. - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success. - gfn space already occupied by other mapping -> fail. The remaining case is where the gfn space happens to be entirely occupied by an existing 1:1 mapping of RMRR that wasn't put there by RMRR code. If you really want to detect this I think a simple reference count of how may times this VM has had the RMRR mapped will do. If that count is 0 and you see a mapping, fail (even if the mapping looks right). Cheers, Tim.