From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH] x86/HVM: honor p2m_ram_ro in
	hvm_map_guest_frame_rw()
Date: Fri, 24 Jul 2015 11:26:47 +0100
Message-ID: <20150724102647.GB30594@zion.uk.xensource.com>
References: <55B224660200007800095083@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=6400f7f3c=wei.liu2@citrix.com>)
	id 1ZIaBo-0003YE-85
	for xen-devel@lists.xenproject.org; Fri, 24 Jul 2015 10:26:52 +0000
Content-Disposition: inline
In-Reply-To: <55B224660200007800095083@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>, Jun Nakajima <jun.nakajima@intel.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Eddie Dong <eddie.dong@intel.com>, Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>, suravee.suthikulpanit@amd.com, xen-devel <xen-devel@lists.xenproject.org>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On Fri, Jul 24, 2015 at 03:41:26AM -0600, Jan Beulich wrote:
> ... and its callers.
> 
> While all non-nested users are made fully honor the semantics of that
> type, doing so in the nested case seemed insane (if doable at all,
> considering VMCS shadowing), and hence there the respective operations
> are simply made fail.
> 
> One case not (yet) taken care of is that of a page getting transitioned
> to this type after a mapping got established.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Beyond that log-dirty handling in _hvm_map_guest_frame() looks bogus
> too: What if a XEN_DOMCTL_SHADOW_OP_* gets issued and acted upon
> between the setting of the dirty flag and the actual write happening?
> I.e. shouldn't the flag instead be set in hvm_unmap_guest_frame()?
> 
> Note that this is conflicting with the altp2m series (adding another
> call to hvm_map_guest_frame_rw(), reviewing of which made me spot the
> issue in the first place).
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3594,8 +3594,8 @@ int hvm_virtual_to_linear_addr(
>  
>  /* On non-NULL return, we leave this function holding an additional 
>   * ref on the underlying mfn, if any */
> -static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable,
> -                                   bool_t permanent)
> +static void *_hvm_map_guest_frame(unsigned long gfn, bool_t permanent,
> +                                  bool_t *writable)
>  {
>      void *map;
>      p2m_type_t p2mt;
> @@ -3618,7 +3618,12 @@ static void *__hvm_map_guest_frame(unsig
>      }
>  
>      if ( writable )

I don't claim I know this piece of code, but checking the pointer but
not the content looks suspicious.

> -        paging_mark_dirty(d, page_to_mfn(page));
> +    {
> +        if ( !p2m_is_discard_write(p2mt) )
> +            paging_mark_dirty(d, page_to_mfn(page));
> +        else
> +            *writable = 0;

You then set *writable here, which makes it even more suspicious.

Wei.