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

Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages



On Fri, Sep 06, 2019 at 04:19:50PM +0200, Jan Beulich wrote:
> On 06.09.2019 16:08, Roger Pau Monné  wrote:
> > On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
> >> On 06.09.2019 13:45, Roger Pau Monné  wrote:
> >>> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> >>>> On 06.09.2019 11:37, Roger Pau Monné  wrote:
> >>>>> On Wed, Jul 03, 2019 at 12:18:45PM +0000, Jan Beulich wrote:
> >>>>>> --- a/xen/arch/x86/mm/p2m.c
> >>>>>> +++ b/xen/arch/x86/mm/p2m.c
> >>>>>> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
> >>>>>>            *
> >>>>>>            * Retain this property by grabbing a writable type ref and 
> >>>>>> then
> >>>>>>            * dropping it immediately.  The result will be pages that 
> >>>>>> have a
> >>>>>> -         * writable type (and an IOMMU entry), but a count of 0 (such 
> >>>>>> that
> >>>>>> -         * any guest-requested type changes succeed and remove the 
> >>>>>> IOMMU
> >>>>>> -         * entry).
> >>>>>> +         * writable type (and an IOMMU entry if necessary), but a 
> >>>>>> count of 0
> >>>>>> +         * (such that any guest-requested type changes succeed and 
> >>>>>> remove the
> >>>>>> +         * IOMMU entry).
> >>>>>>            */
> >>>>>>           for ( i = 0; i < (1UL << page_order); ++i, ++page )
> >>>>>>           {
> >>>>>> -            if ( !need_iommu_pt_sync(d) )
> >>>>>> +            if ( !iommu_enabled )
> >>>>>
> >>>>> That's kind of a strong check for a domain that might never use the
> >>>>> iommu at all. Isn't it fine to just rely on
> >>>>> arch_iommu_populate_page_table finding non-writable pages and thus not
> >>>>> adding them to the iommu page-tables?
> >>>>
> >>>> No - the code change here is to take care of page additions to
> >>>> the domain after it has booted.
> >>>
> >>> Please bear with me, but AFAICT arch_iommu_populate_page_table could
> >>> be used after the domain has booted if a pci device is hot plugged.
> >>>
> >>> If this is to deal with additions to domains having an iommu already
> >>> enabled, isn't it enough to use need_iommu_pt_sync?
> >>>
> >>> That's going to return true for all PV domains, except for dom0 not
> >>> running in strict mode, which is expected because in that case dom0
> >>> already has the whole RAM mapped into the iommu page-tables?
> >>
> >> Well, my previous reply wasn't precise enough, I guess. The change
> >> really is about both cases: If the domain is already using an IOMMU,
> >> need_iommu_pt_sync() would be enough indeed. If IOMMU use _may_ be
> >> enabled later on, we need to transition pages out of their initial
> >> PGT_none state right away. If we deferred this until the point
> >> where the IOMMU gets enabled for the domain, we'd have to watch out
> >> for PGT_none pages there, which would be extra hassle.
> > 
> > I still think a relaxed PV dom0 should avoid the overhead of
> > get_page_and_type, and the iommu flush done afterwards, as it already
> > has all host RAM into it's iommu page-tables.
> > 
> > Ie: I think the check should be something like:
> > 
> > if ( !iommu_enabled ||
> >      (is_hardware_domain(d) && !need_iommu_pt_sync(d) )
> 
> Ah, yes, I can certainly do this (if the patch doesn't become
> unnecessary anyway).

With that please add my Reviewed-by: Roger Pau Monné
<roger.pau@xxxxxxxxxx>, albeit as you say I'm not sure whether this is
really needed in light of the upcoming iommu changes.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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