[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, Feb 17, 2015 at 12:33:12PM +0000, Jan Beulich wrote:
> >>> 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).

Agree.
> 
> > @@ -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.

I discussed it with Konrad and it was an option, but I used that
approach. Now looks like everyone is agree with adding extra RMRRs
derived from command-line to existing list of RMRRs, I will post next
version and will do it this way.
I am not sure though if there is need to distinguish between these extra RMRRs
regions and the ones derived from ACPI.

> 
> Jan
> 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.