xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [PATCH 2/7] iommu: make use of type-safe BFN and MFN in exported functions
Date: Fri, 16 Mar 2018 10:26:08 +0000	[thread overview]
Message-ID: <2ba06491433e443d9d225de95094d311@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5AAAA30A02000078001B2447@prv-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 15 March 2018 15:45
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Julien Grall <julien.grall@arm.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; Wei Liu <wei.liu2@citrix.com>; George
> Dunlap <George.Dunlap@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>;
> Jun Nakajima <jun.nakajima@intel.com>; Kevin Tian
> <kevin.tian@intel.com>; Stefano Stabellini <sstabellini@kernel.org>; xen-
> devel@lists.xenproject.org; Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>; Tim (Xen.org) <tim@xen.org>
> Subject: Re: [PATCH 2/7] iommu: make use of type-safe BFN and MFN in
> exported functions
> 
> >>> On 12.02.18 at 11:47, <paul.durrant@citrix.com> wrote:
> > This patch modifies the declaration of the entry points to the IOMMU
> > sub-system to use bfn_t and mfn_t in place of unsigned long. A
> subsequent
> > patch will similarly modify the methods in the iommu_ops structure.
> >
> > NOTE: Since (with this patch applied) bfn_t is now in use, the patch also
> >       introduces the 'cscope/grep fodder' to allow the type declaration to
> >       be easily found.
> 
> Ah, here we go. But I continue to think this belong in patch 1.
> 

Ok. I debated it with myself when I wrote the original patches. I'll move the relevant hunks.

> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2676,13 +2676,12 @@ static int _get_page_type(struct page_info
> *page, unsigned long type,
> >          struct domain *d = page_get_owner(page);
> >          if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> >          {
> > -            gfn_t gfn = _gfn(mfn_to_gmfn(d, mfn_x(page_to_mfn(page))));
> > +            bfn_t bfn = _bfn(mfn_to_gmfn(d, mfn_x(page_to_mfn(page))));
> >
> >              if ( (x & PGT_type_mask) == PGT_writable_page )
> > -                iommu_ret = iommu_unmap_page(d, gfn_x(gfn));
> > +                iommu_ret = iommu_unmap_page(d, bfn);
> >              else if ( type == PGT_writable_page )
> > -                iommu_ret = iommu_map_page(d, gfn_x(gfn),
> > -                                           mfn_x(page_to_mfn(page)),
> > +                iommu_ret = iommu_map_page(d, bfn, page_to_mfn(page),
> 
> Along the lines of what I've said earlier about mixing address spaces,
> this would perhaps not so much need a comment (it's a 1:1 mapping
> after all), but rather making more obvious that it's a 1:1 mapping.
> This in particular would mean to me to latch page_to_mfn(page) into
> a (neutrally named, e.g. "frame") local variable, and use the result in
> a way that makes obviously especially on the "map" path that this
> really requests a 1:1 mapping. By implication from the 1:1 mapping
> it'll then (hopefully) be clear to the reader that which exact name
> space is used doesn't really matter.

Ok, I'll re-phrase things in v2.

> 
> > --- a/xen/arch/x86/mm/p2m-ept.c
> > +++ b/xen/arch/x86/mm/p2m-ept.c
> > @@ -873,12 +873,14 @@ out:
> >              if ( iommu_flags )
> >                  for ( i = 0; i < (1 << order); i++ )
> >                  {
> > -                    rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
> > +                    rc = iommu_map_page(d, _bfn(gfn + i), mfn_add(mfn, i),
> > +                                        iommu_flags);
> >                      if ( unlikely(rc) )
> >                      {
> >                          while ( i-- )
> >                              /* If statement to satisfy __must_check. */
> > -                            if ( iommu_unmap_page(p2m->domain, gfn + i) )
> > +                            if ( iommu_unmap_page(p2m->domain,
> > +                                                  _bfn(gfn + i)) )
> 
> The fundamental issue of mixed address spaces continues ...
> 

I'll add appropriately an appropriately named stack variable.

> > @@ -781,14 +781,14 @@ guest_physmap_add_entry(struct domain *d,
> gfn_t gfn, mfn_t mfn,
> >          {
> >              for ( i = 0; i < (1 << page_order); i++ )
> >              {
> > -                rc = iommu_map_page(d, mfn_x(mfn_add(mfn, i)),
> > -                                    mfn_x(mfn_add(mfn, i)),
> > +                rc = iommu_map_page(d, _bfn(mfn_x(mfn) + i),
> > +                                    mfn_add(mfn, i),
> 
> Please check whether some line wrapping can now be avoided, like
> apparently here.
> 

Ok.

> > @@ -1164,7 +1164,9 @@ int set_identity_p2m_entry(struct domain *d,
> unsigned long gfn_l,
> >      {
> >          if ( !need_iommu(d) )
> >              return 0;
> > -        return iommu_map_page(d, gfn_l, gfn_l,
> IOMMUF_readable|IOMMUF_writable);
> > +
> > +        return iommu_map_page(d, _bfn(gfn_l), _mfn(gfn_l),
> > +                              IOMMUF_readable|IOMMUF_writable);
> 
> Please add spaces around | as you touch this (also elsewhere).
> 

Ok.

> > @@ -1254,7 +1256,8 @@ int clear_identity_p2m_entry(struct domain *d,
> unsigned long gfn_l)
> >      {
> >          if ( !need_iommu(d) )
> >              return 0;
> > -        return iommu_unmap_page(d, gfn_l);
> > +
> > +        return iommu_unmap_page(d, _bfn(gfn_l));
> >      }
> 
> No real need for the extra blank line here, as this isn't the main return
> point.
> 

Ok.

  Paul

> Jan

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

  reply	other threads:[~2018-03-16 10:26 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 10:47 [PATCH 0/7] paravirtual IOMMU interface Paul Durrant
2018-02-12 10:47 ` [PATCH 1/7] iommu: introduce the concept of BFN Paul Durrant
2018-03-15 13:39   ` Jan Beulich
2018-03-16 10:31     ` Paul Durrant
2018-03-16 10:39       ` Jan Beulich
2018-02-12 10:47 ` [PATCH 2/7] iommu: make use of type-safe BFN and MFN in exported functions Paul Durrant
2018-03-15 15:44   ` Jan Beulich
2018-03-16 10:26     ` Paul Durrant [this message]
2018-07-10 14:29     ` George Dunlap
2018-07-10 14:34       ` Jan Beulich
2018-07-10 14:37         ` Andrew Cooper
2018-07-10 14:58         ` George Dunlap
2018-07-10 15:19           ` Jan Beulich
2018-02-12 10:47 ` [PATCH 3/7] iommu: push use of type-safe BFN and MFN into iommu_ops Paul Durrant
2018-03-15 16:15   ` Jan Beulich
2018-03-16 10:22     ` Paul Durrant
2018-02-12 10:47 ` [PATCH 4/7] vtd: add lookup_page method to iommu_ops Paul Durrant
2018-03-15 16:54   ` Jan Beulich
2018-03-16 10:19     ` Paul Durrant
2018-03-16 10:28       ` Jan Beulich
2018-03-16 10:41         ` Paul Durrant
2018-02-12 10:47 ` [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op Paul Durrant
2018-02-13  6:43   ` Tian, Kevin
2018-02-13  9:22     ` Paul Durrant
2018-02-23  5:17       ` Tian, Kevin
2018-02-23  9:41         ` Paul Durrant
2018-02-24  2:57           ` Tian, Kevin
2018-02-26  9:57             ` Paul Durrant
2018-02-26 11:55               ` Tian, Kevin
2018-02-27  5:05               ` Tian, Kevin
2018-02-27  9:32                 ` Paul Durrant
2018-02-28  2:53                   ` Tian, Kevin
2018-02-28  8:55                     ` Paul Durrant
2018-03-16 12:25   ` Jan Beulich
2018-06-07 11:42     ` Paul Durrant
2018-06-07 13:21       ` Jan Beulich
2018-06-07 13:45         ` George Dunlap
2018-06-07 14:06           ` Paul Durrant
2018-06-07 14:21             ` Ian Jackson
2018-06-07 15:21               ` Paul Durrant
2018-06-07 15:41                 ` Jan Beulich
2018-02-12 10:47 ` [PATCH 6/7] x86: add iommu_op to query reserved ranges Paul Durrant
2018-02-13  6:51   ` Tian, Kevin
2018-02-13  9:25     ` Paul Durrant
2018-02-23  5:23       ` Tian, Kevin
2018-02-23  9:02         ` Jan Beulich
2018-03-19 14:10   ` Jan Beulich
2018-03-19 15:13     ` Paul Durrant
2018-03-19 16:30       ` Jan Beulich
2018-03-19 15:13   ` Jan Beulich
2018-03-19 15:36     ` Paul Durrant
2018-03-19 16:31       ` Jan Beulich
2018-02-12 10:47 ` [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB Paul Durrant
2018-02-13  6:55   ` Tian, Kevin
2018-02-13  9:55     ` Paul Durrant
2018-02-23  5:35       ` Tian, Kevin
2018-02-23  9:35         ` Paul Durrant
2018-02-24  3:01           ` Tian, Kevin
2018-02-26  9:38             ` Paul Durrant
2018-03-19 15:11   ` Jan Beulich
2018-03-19 15:34     ` Paul Durrant
2018-03-19 16:49       ` Jan Beulich
2018-03-19 16:57         ` Paul Durrant
2018-03-20  8:11           ` Jan Beulich
2018-03-20  9:32             ` Paul Durrant
2018-03-20  9:49               ` Jan Beulich
2018-02-13  6:21 ` [PATCH 0/7] paravirtual IOMMU interface Tian, Kevin
2018-02-13  9:18   ` Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ba06491433e443d9d225de95094d311@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).