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
next prev parent 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).