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

Re: [Xen-devel] [PATCH v3 1/2] VT-d: re-phrase logic in vtd_set_hwdom_mapping() for clarity



> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: 21 June 2018 08:17
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Jan
> Beulich <jbeulich@xxxxxxxx>; Julien Grall <julien.grall@xxxxxxx>; Konrad
> Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>
> Subject: RE: [PATCH v3 1/2] VT-d: re-phrase logic in
> vtd_set_hwdom_mapping() for clarity
> 
> > From: Paul Durrant [mailto:paul.durrant@xxxxxxxxxx]
> > Sent: Saturday, June 16, 2018 12:31 AM
> >
> > It is hard to reconcile the comment at the top of the loop in
> > vtd_set_hwdom_mapping() with the if statement following it. This patch
> > re-phrases the logic, preserving the semantics, but making it easier
> > to read.
> >
> > The patch also modifies the Xen command line documentation to make it
> > clear that iommu_inclusive_mapping only applies to pages up to the 4GB
> > boundary.
> >
> > NOTE: This patch also corrects the indentation of the printk() towards
> >       the end of vtd_set_hwdom_mapping().
> >
> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > Reviewed-by: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> 
> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>, with one small comment
> below
> 
> > ---
> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: Julien Grall <julien.grall@xxxxxxx>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > Cc: Tim Deegan <tim@xxxxxxx>
> > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> > Cc: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > v3:
> >  - Fix top calculation by introducing max_pfn.
> >  - Move comment.
> >
> > v2:
> >  - Compare against GB(4) rather than 0xffffffff.
> > ---
> >  docs/misc/xen-command-line.markdown   |  4 ++--
> >  xen/drivers/passthrough/vtd/x86/vtd.c | 34 +++++++++++++++++++------
> ---
> > ------
> >  2 files changed, 21 insertions(+), 17 deletions(-)
> >
> > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-
> > command-line.markdown
> > index 8712a833a2..b75471b51a 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1212,8 +1212,8 @@ wait descriptor timed out', try increasing this
> > value.
> >
> >  Use this to work around firmware issues providing incorrect RMRR entries.
> >  Rather than only mapping RAM pages for IOMMU accesses for Dom0, with
> > this
> > -option all pages not marked as unusable in the E820 table will get a
> > mapping
> > -established.
> > +option all pages up to 4GB, not marked as unusable in the E820 table, will
> > +get a mapping established.
> >
> >  ### irq\_ratelimit (x86)
> >  > `= <integer>`
> > diff --git a/xen/drivers/passthrough/vtd/x86/vtd.c
> > b/xen/drivers/passthrough/vtd/x86/vtd.c
> > index 88a60b3307..6551f01e31 100644
> > --- a/xen/drivers/passthrough/vtd/x86/vtd.c
> > +++ b/xen/drivers/passthrough/vtd/x86/vtd.c
> > @@ -110,30 +110,34 @@ void hvm_dpci_isairq_eoi(struct domain *d,
> > unsigned int isairq)
> >
> >  void __hwdom_init vtd_set_hwdom_mapping(struct domain *d)
> >  {
> > -    unsigned long i, j, tmp, top;
> > +    unsigned long i, j, tmp, top, max_pfn;
> >
> >      BUG_ON(!is_hardware_domain(d));
> >
> > -    top = max(max_pdx, pfn_to_pdx(0xffffffffUL >> PAGE_SHIFT) + 1);
> > +    max_pfn = (GB(4) >> PAGE_SHIFT) - 1;
> > +    top = max(max_pdx, pfn_to_pdx(max_pfn) + 1);
> >
> >      for ( i = 0; i < top; i++ )
> >      {
> > +        unsigned long pfn = pdx_to_pfn(i);
> > +        bool map;
> >          int rc = 0;
> >
> >          /*
> > -         * Set up 1:1 mapping for dom0. Default to use only conventional 
> > RAM
> > -         * areas and let RMRRs include needed reserved regions. When set,
> > the
> > -         * inclusive mapping maps in everything below 4GB except unusable
> > -         * ranges.
> > +         * Set up 1:1 mapping for dom0. Default to include only
> > +         * conventional RAM areas and let RMRRs include needed reserved
> > +         * regions. When set, the inclusive mapping maps in every pfn up
> > +         * to 4GB except those that fall in unusable ranges.
> >           */
> 
> I'm not sure whether others feel same as me. I read the last sentence
> as if 'inclusive mapping' ONLY maps <4GB frames while leaving >=4GB
> frames unmapped. If it is the case, adding a 'further' i.e. "the inclusive
> mapping further maps" sounds more clear?

Agreed. Although I'd probably go for 'additionally' rather than 'further'. 
Hopefully this is something that can be fixed up at commit time.

  Paul

> 
> > -        unsigned long pfn = pdx_to_pfn(i);
> > +        if ( pfn > max_pfn && !mfn_valid(_mfn(pfn)) )
> > +            continue;
> > +
> > +        if ( iommu_inclusive_mapping && pfn <= max_pfn )
> > +            map = !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE);
> > +        else
> > +            map = page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL);
> >
> > -        if ( pfn > (0xffffffffUL >> PAGE_SHIFT) ?
> > -             (!mfn_valid(_mfn(pfn)) ||
> > -              !page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL)) :
> > -             iommu_inclusive_mapping ?
> > -             page_is_ram_type(pfn, RAM_TYPE_UNUSABLE) :
> > -             !page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) )
> > +        if ( !map )
> >              continue;
> >
> >          /* Exclude Xen bits */
> > @@ -151,8 +155,8 @@ void __hwdom_init
> > vtd_set_hwdom_mapping(struct domain *d)
> >          }
> >
> >          if ( rc )
> > -           printk(XENLOG_WARNING VTDPREFIX " d%d: IOMMU mapping
> > failed: %d\n",
> > -                  d->domain_id, rc);
> > +            printk(XENLOG_WARNING VTDPREFIX " d%d: IOMMU mapping
> > failed: %d\n",
> > +                   d->domain_id, rc);
> >
> >          if (!(i & (0xfffff >> (PAGE_SHIFT - PAGE_SHIFT_4K))))
> >              process_pending_softirqs();
> > --
> > 2.11.0


_______________________________________________
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®.