All of lore.kernel.org
 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>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.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>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	Brian Woods <brian.woods@amd.com>
Subject: Re: [PATCH v6 10/14] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()
Date: Tue, 11 Sep 2018 15:40:03 +0000	[thread overview]
Message-ID: <6fdadeea76e944fcbdcf9f2b0a43025a@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5B97D1A902000078001E75A2@prv1-mh.provo.novell.com>

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 11 September 2018 15:31
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Kevin Tian <kevin.tian@intel.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Wei Liu <wei.liu2@citrix.com>; Jun Nakajima
> <jun.nakajima@intel.com>; Razvan Cojocaru <rcojocaru@bitdefender.com>;
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>; George Dunlap
> <George.Dunlap@citrix.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; Tim
> (Xen.org) <tim@xen.org>; Julien Grall <julien.grall@arm.com>; Tamas K
> Lengyel <tamas@tklengyel.com>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> devel@lists.xenproject.org>; Brian Woods <brian.woods@amd.com>
> Subject: Re: [Xen-devel] [PATCH v6 10/14] mm / iommu: split need_iommu()
> into has_iommu_pt() and need_iommu_pt_sync()
> 
> >>> On 23.08.18 at 11:47, <paul.durrant@citrix.com> wrote:
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -793,7 +793,8 @@ HVM_REGISTER_SAVE_RESTORE(MTRR,
> hvm_save_mtrr_msr, hvm_load_mtrr_msr,
> >
> >  void memory_type_changed(struct domain *d)
> >  {
> > -    if ( need_iommu(d) && d->vcpu && d->vcpu[0] )
> > +    if ( (need_iommu_pt_sync(d) || iommu_use_hap_pt(d)) &&
> > +         d->vcpu && d->vcpu[0] )
> >      {
> >          p2m_memory_type_changed(d);
> >          flush_all(FLUSH_CACHE);
> 
> How does need_iommu_pt_sync() come into play here? To me,
> has_iommu_pt() would seem to be a better match.

Ok.

> The question
> here solely is (iirc) whether memory types take any effect in the
> first place (or else we can skip adjusting them), which in turn
> solely depends on whether there are any pass-through devices
> in the domain. This is along the lines of ...
> 
> > @@ -841,7 +842,7 @@ int epte_get_entry_emt(struct domain *d,
> unsigned long gfn, mfn_t mfn,
> >          return MTRR_TYPE_UNCACHABLE;
> >      }
> >
> > -    if ( !need_iommu(d) && !cache_flush_permitted(d) )
> > +    if ( !has_iommu_pt(d) && !cache_flush_permitted(d) )
> >      {
> >          *ipat = 1;
> >          return MTRR_TYPE_WRBACK;
> 
> ... this.
> 
> > --- a/xen/arch/x86/x86_64/mm.c
> > +++ b/xen/arch/x86/x86_64/mm.c
> > @@ -1426,7 +1426,8 @@ int memory_add(unsigned long spfn, unsigned
> long epfn, unsigned int pxm)
> >      if ( ret )
> >          goto destroy_m2p;
> >
> > -    if ( iommu_enabled && !iommu_passthrough &&
> !need_iommu(hardware_domain) )
> > +    if ( iommu_enabled && !iommu_passthrough &&
> > +         !need_iommu_pt_sync(hardware_domain) )
> >      {
> >          for ( i = spfn; i < epfn; i++ )
> >              if ( iommu_map_page(hardware_domain, _bfn(i), _mfn(i),
> 
> I'm confused - the condition you change looks to be inverted. Wouldn't
> we better fix this?

I don't think it is inverted. I think this is to add new hotplugged memory to the 1:1 map in the case that dom0 is not in strict mode. I could be wrong. George?

> 
> And then I again wonder whether you've chosen the right predicate:
> Where would the equivalent mappings come from in the opposite case?
> 

If dom0 is in strict mode then I assume that the synchronization is handled when the calls are made to add memory into the p2m (which IIRC happens even for PV guests). My aim for this patch is to avoid any visible functional change.

> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -805,8 +805,8 @@ int xenmem_add_to_physmap(struct domain *d,
> struct xen_add_to_physmap *xatp,
> >      xatp->size -= start;
> >
> >  #ifdef CONFIG_HAS_PASSTHROUGH
> > -    if ( need_iommu(d) )
> > -        this_cpu(iommu_dont_flush_iotlb) = 1;
> > +    if ( need_iommu_pt_sync(d) || iommu_use_hap_pt(d) )
> > +       this_cpu(iommu_dont_flush_iotlb) = 1;
> >  #endif
> 
> Rather than making the conditional more complicated, perhaps
> simply drop it (and move the reset-to-false code out of ...
> 
> > @@ -828,7 +828,7 @@ int xenmem_add_to_physmap(struct domain *d,
> struct xen_add_to_physmap *xatp,
> >      }
> >
> >  #ifdef CONFIG_HAS_PASSTHROUGH
> > -    if ( need_iommu(d) )
> > +    if ( need_iommu_pt_sync(d) || iommu_use_hap_pt(d) )
> >      {
> >          int ret;
> 
> ... this if())?
> 
> Also it looks to me as if here you've got confused by the meaning
> you've assigned to need_iommu_pt_sync(): According to the
> description, it is about sync-ing of page tables. Here, however,
> we're checking whether to flush TLBs.
> 

Yes, I may be confused here but it would seem to me that flushing the IOTLB would be necessary even in the case where the page tables are shared. I'll check the logic again.

> > @@ -179,8 +179,10 @@ void __hwdom_init iommu_hwdom_init(struct
> domain *d)
> >          return;
> >
> >      register_keyhandler('o', &iommu_dump_p2m_table, "dump iommu
> p2m table", 0);
> > -    d->need_iommu = !!iommu_dom0_strict;
> > -    if ( need_iommu(d) && !iommu_use_hap_pt(d) )
> > +
> > +    hd->status = IOMMU_STATUS_initializing;
> > +    hd->need_sync = !!iommu_dom0_strict && !iommu_use_hap_pt(d);
> 
> Pointless !! afaict.
> 

Ok, I'll drop it.

> >  int iommu_construct(struct domain *d)
> >  {
> > -    if ( need_iommu(d) > 0 )
> > +    struct domain_iommu *hd = dom_iommu(d);
> > +
> > +    if ( hd->status == IOMMU_STATUS_initialized )
> >          return 0;
> >
> > -    if ( !iommu_use_hap_pt(d) )
> > +    if ( !iommu_use_hap_pt(d) && hd->status <
> IOMMU_STATUS_initialized )
> 
> Isn't the addition here redundant with the earlier if()?
> 

Yes, it does appear to be.

> > @@ -889,9 +886,11 @@ void watchdog_domain_destroy(struct domain
> *d);
> >  #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
> >                             cpumask_weight((v)->cpu_hard_affinity) == 1)
> >  #ifdef CONFIG_HAS_PASSTHROUGH
> > -#define need_iommu(d)    ((d)->need_iommu)
> > +#define has_iommu_pt(d) (dom_iommu(d)->status !=
> IOMMU_STATUS_disabled)
> > +#define need_iommu_pt_sync(d) (dom_iommu(d)->need_sync)
> >  #else
> > -#define need_iommu(d)    (0)
> > +#define has_iommu_pt(d) (0)
> > +#define need_iommu_pt_sync(d) (0)
> 
> Please use false here (and no need for the parentheses).
> 

Ok.

  Paul

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

  reply	other threads:[~2018-09-11 16:07 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23  9:46 [PATCH v6 00/14] paravirtual IOMMU interface Paul Durrant
2018-08-23  9:46 ` [PATCH v6 01/14] iommu: introduce the concept of BFN Paul Durrant
2018-08-30 15:59   ` Jan Beulich
2018-09-03  8:23     ` Paul Durrant
2018-09-03 11:46       ` Jan Beulich
2018-09-04  6:48         ` Tian, Kevin
2018-09-04  8:32           ` Jan Beulich
2018-09-04  8:37             ` Tian, Kevin
2018-09-04  8:47               ` Jan Beulich
2018-09-04  8:49                 ` Paul Durrant
2018-09-04  9:08                   ` Jan Beulich
2018-09-05  0:42                     ` Tian, Kevin
2018-09-05  6:48                       ` Jan Beulich
2018-09-05  6:56                         ` Tian, Kevin
2018-09-05  7:11                           ` Jan Beulich
2018-09-05  9:13                             ` Paul Durrant
2018-09-05  9:38                               ` Jan Beulich
2018-09-06 10:36                                 ` Paul Durrant
2018-09-06 13:13                                   ` Jan Beulich
2018-09-06 14:54                                     ` Paul Durrant
2018-09-07  1:47                                       ` Tian, Kevin
2018-09-07  6:24                                         ` Jan Beulich
2018-09-07  8:13                                           ` Paul Durrant
2018-09-07  8:16                                             ` Tian, Kevin
2018-09-07  8:25                                               ` Paul Durrant
2018-08-23  9:46 ` [PATCH v6 02/14] iommu: make use of type-safe BFN and MFN in exported functions Paul Durrant
2018-09-04 10:29   ` Jan Beulich
2018-08-23  9:47 ` [PATCH v6 03/14] iommu: push use of type-safe BFN and MFN into iommu_ops Paul Durrant
2018-09-04 10:32   ` Jan Beulich
2018-08-23  9:47 ` [PATCH v6 04/14] iommu: don't domain_crash() inside iommu_map/unmap_page() Paul Durrant
2018-09-04 10:38   ` Jan Beulich
2018-09-04 10:39     ` Paul Durrant
2018-08-23  9:47 ` [PATCH v6 05/14] public / x86: introduce __HYPERCALL_iommu_op Paul Durrant
2018-09-04 11:50   ` Jan Beulich
2018-09-04 12:23     ` Paul Durrant
2018-09-04 12:55       ` Jan Beulich
2018-09-04 13:17         ` Paul Durrant
2018-09-07 10:52   ` Jan Beulich
2018-08-23  9:47 ` [PATCH v6 06/14] iommu: track reserved ranges using a rangeset Paul Durrant
2018-09-07 10:40   ` Jan Beulich
2018-09-11  9:28     ` Paul Durrant
2018-08-23  9:47 ` [PATCH v6 07/14] x86: add iommu_op to query reserved ranges Paul Durrant
2018-09-07 11:01   ` Jan Beulich
2018-09-11  9:34     ` Paul Durrant
2018-09-11  9:43       ` Jan Beulich
2018-09-13  6:11     ` Tian, Kevin
2018-08-23  9:47 ` [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops Paul Durrant
2018-09-07 11:11   ` Jan Beulich
2018-09-07 12:36     ` Paul Durrant
2018-09-07 14:56       ` Jan Beulich
2018-09-07 15:24         ` Paul Durrant
2018-09-07 15:52           ` Jan Beulich
2018-09-12  8:31     ` Paul Durrant
2018-09-12  8:43       ` Jan Beulich
2018-09-12  8:45         ` Paul Durrant
2018-09-12  8:51           ` Paul Durrant
2018-09-12  8:53             ` Paul Durrant
2018-09-12  9:03               ` Jan Beulich
2018-09-12  9:05                 ` Paul Durrant
2018-09-12  9:12                   ` Jan Beulich
2018-09-12  9:15                     ` Paul Durrant
2018-09-12  9:21                       ` Jan Beulich
2018-09-12  9:30                         ` Paul Durrant
2018-09-12 10:07                           ` Jan Beulich
2018-09-12 10:09                             ` Paul Durrant
2018-09-12 12:15                               ` Jan Beulich
2018-09-12 12:22                                 ` Paul Durrant
2018-09-12 12:39                                   ` Jan Beulich
2018-09-12 12:53                                     ` Paul Durrant
2018-09-12 13:19                                       ` Jan Beulich
2018-09-12 13:25                                         ` Paul Durrant
2018-09-12 13:39                                           ` Jan Beulich
2018-09-12 13:43                                             ` Paul Durrant
2018-09-12  8:59           ` Jan Beulich
2018-08-23  9:47 ` [PATCH v6 09/14] mm / iommu: include need_iommu() test in iommu_use_hap_pt() Paul Durrant
2018-09-07 11:20   ` Jan Beulich
2018-09-11  9:39     ` Paul Durrant
2018-09-11  9:47       ` Jan Beulich
2018-09-13  6:23         ` Tian, Kevin
2018-09-13  8:34           ` Paul Durrant
2018-08-23  9:47 ` [PATCH v6 10/14] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync() Paul Durrant
2018-08-23 11:10   ` Razvan Cojocaru
2018-09-11 14:31   ` Jan Beulich
2018-09-11 15:40     ` Paul Durrant [this message]
2018-09-12  6:45       ` Jan Beulich
2018-09-12  8:07         ` Paul Durrant
2018-08-23  9:47 ` [PATCH v6 11/14] x86: add iommu_op to enable modification of IOMMU mappings Paul Durrant
2018-09-11 14:48   ` Jan Beulich
2018-09-11 15:52     ` Paul Durrant
2018-09-12  6:53       ` Jan Beulich
2018-09-12  8:04         ` Paul Durrant
2018-08-23  9:47 ` [PATCH v6 12/14] memory: add get_paged_gfn() as a wrapper Paul Durrant
2018-08-23 10:24   ` Julien Grall
2018-08-23 10:30     ` Paul Durrant
2018-09-11 14:56   ` Jan Beulich
2018-09-12  9:10     ` Paul Durrant
2018-09-12  9:15       ` Jan Beulich
2018-09-12 10:01         ` George Dunlap
2018-09-12 10:08           ` Paul Durrant
2018-09-12 10:10           ` Jan Beulich
2018-08-23  9:47 ` [PATCH v6 13/14] x86: add iommu_ops to modify and flush IOMMU mappings Paul Durrant
2018-09-11 15:15   ` Jan Beulich
2018-09-12  7:03   ` Jan Beulich
2018-09-12  8:02     ` Paul Durrant
2018-09-12  8:27       ` Jan Beulich
2018-09-13  6:41       ` Tian, Kevin
2018-09-13  8:32         ` Paul Durrant
2018-09-13  8:49         ` Jan Beulich
2018-08-23  9:47 ` [PATCH v6 14/14] x86: extend the map and unmap iommu_ops to support grant references Paul Durrant
2018-09-12 14:12   ` Jan Beulich
2018-09-12 16:28     ` 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=6fdadeea76e944fcbdcf9f2b0a43025a@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=brian.woods@amd.com \
    --cc=julien.grall@arm.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tamas@tklengyel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.