Re: [Xen-devel] [PATCH RFC 4/5] pvh: dom0 add rw mapping for dom0_iommu_rwmem boot opt

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.02.15 at 19:52, <elena.ufimtseva@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -730,7 +730,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
> mfn_t mfn,
>      }
>  
>      if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
> -         (p2mt == p2m_ram_paging_in) )
> +         (p2mt == p2m_ram_paging_in) || (p2mt == p2m_sys_rw) )

This looks pretty arbitrary and hence would at least need brief
mentioning in the patch description. I'm not convinced of the need
for a new P2M type anyway (after all we don't need such for RMRRs
either, and iirc you really want extra RMRR-like regions here).

> @@ -750,8 +750,8 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
> mfn_t mfn,
>          new_entry.mfn = mfn_x(mfn);
>  
>          /* Safe to read-then-write because we hold the p2m lock */
> -        if ( ept_entry->mfn == new_entry.mfn )
> -             need_modify_vtd_table = 0;
> +        if ( ept_entry->mfn == new_entry.mfn && ept_entry->sa_p2mt == 
> new_entry.sa_p2mt )
> +            need_modify_vtd_table = 0;

This added conditions deserves explanation too.

For all further changes done here, I'd really like to first understand
why you don't simply add extra RMRRs based on the command line
option introduced in the next patch, as that would appear to make
most of what you do here unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel