From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v7 02/10] arch/arm: add consistency check to REMOVE p2m changes Date: Tue, 06 May 2014 17:52:17 +0100 Message-ID: <53691341.2000508@linaro.org> References: <1399305254-3695-1-git-send-email-avanzini.arianna@gmail.com> <1399305254-3695-3-git-send-email-avanzini.arianna@gmail.com> <536912F7.6010903@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <536912F7.6010903@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Arianna Avanzini , xen-devel@lists.xen.org Cc: paolo.valente@unimore.it, keir@xen.org, stefano.stabellini@eu.citrix.com, tim@xen.org, dario.faggioli@citrix.com, Ian.Jackson@eu.citrix.com, Ian.Campbell@eu.citrix.com, etrudeau@broadcom.com, JBeulich@suse.com, andrew.cooper3@citrix.com, viktor.kleinik@globallogic.com List-Id: xen-devel@lists.xenproject.org On 05/06/2014 05:51 PM, Julien Grall wrote: > Hi Arianna, > > On 05/05/2014 04:54 PM, Arianna Avanzini wrote: >> Currently, the REMOVE case of the switch in apply_p2m_changes() >> does not perform any consistency check on the mapping to be removed. >> More in detail, the code does not check if the guest address to be >> unmapped is actually mapped to the machine address given as a >> parameter. >> This commit attempts to add the above-described consistency check >> to the REMOVE path of apply_p2m_changes(). This is instrumental to >> one of the following commits which implements the possibility to >> trigger the removal of p2m ranges via the memory_mapping DOMCTL >> for ARM. >> >> Signed-off-by: Arianna Avanzini >> Acked-by: Stefano Stabellini >> Cc: Dario Faggioli >> Cc: Paolo Valente >> Cc: Julien Grall >> Cc: Ian Campbell >> Cc: Jan Beulich >> Cc: Keir Fraser >> Cc: Tim Deegan >> Cc: Ian Jackson >> Cc: Andrew Cooper >> Cc: Eric Trudeau >> Cc: Viktor Kleinik >> >> --- >> >> v7: >> - Silently ignore the fact that, when removing a mapping, the specified >> gfn is not mapped at all. > > I think you misunderstood my previous comment. I didn't ask to remove > "maddr += ...". This code was right. Now the failure (i.e the MFN > doesn't match the GFN) is obscure. > > On x86, Xen will continue to unmap even if we fail to remove one entry. > Of course, it will return an error at the end. I forgot to add: it would be nice to have some print message as x86 does. -- Julien Grall