Re: [PATCH] x86/HVM: honor p2m_ram_ro in hvm_map_guest_frame_rw()

[Wei Liu <wei.liu2@citrix.com>]

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.