Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 27 November 2018 13:07
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Brian Woods <brian.woods@xxxxxxx>; Suravee Suthikulpanit
> <suravee.suthikulpanit@xxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> 
> >>> On 26.11.18 at 18:30, <paul.durrant@xxxxxxxxxx> wrote:
> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
> used
> > to be specified as ignored. However, bits 5 and 6 are now specified as
> > 'accessed' and 'dirty' bits and their use only remains safe as long as
> > the DTE 'Host Access Dirty' bits remain clear.
> 
> Upon second thought - is this actually true with the XSA-275
> changes in place? As long as the domain is not running yet,
> how would A and/or D bits get set?

Ok, I can amend the comment. The risk is, as I say, predicated on the bits in 
the DTE anyway but the tables are wired into the DTE *before* being populated 
so I don't think there is anything to stop h/w DMAing whilst they are being 
constructed.

> 
> > @@ -698,55 +569,14 @@ int amd_iommu_map_page(struct domain *d, dfn_t
> dfn, mfn_t mfn,
> >          return -EFAULT;
> >      }
> >
> > -    /* Install 4k mapping first */
> > +    /* Install 4k mapping */
> >      need_flush = set_iommu_pte_present(pt_mfn[1], dfn_x(dfn),
> mfn_x(mfn), 1,
> >                                         !!(flags & IOMMUF_writable),
> >                                         !!(flags & IOMMUF_readable));
> >
> >      if ( need_flush )
> > -    {
> >          amd_iommu_flush_pages(d, dfn_x(dfn), 0);
> > -        /* No further merging, as the logic doesn't cope. */
> > -        hd->arch.no_merge = true;
> 
> Besides removing the uses of this field, which was introduced for
> XSA-275, you should then also remove the field itself I think.

Yes, I missed that.

  Paul

> 
> Jan
> 


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