iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Derrick, Jonathan" <jonathan.derrick@intel.com>
To: "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"drake@endlessm.com" <drake@endlessm.com>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux@endlessm.com" <linux@endlessm.com>
Subject: Re: [PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed
Date: Thu, 27 Feb 2020 18:19:28 +0000	[thread overview]
Message-ID: <199bcea7d614e57261ee34a02c8096e6ce725629.camel@intel.com> (raw)
In-Reply-To: <f8f494fa-3fc5-637a-ddab-0d25cc56262e@linux.intel.com>

Hi Baolu, Daniel,

Sorry for the delay. Was offline for the last week.

On Thu, 2020-02-20 at 19:58 +0800, Lu Baolu wrote:
> Hi,
> 
> On 2020/2/20 18:06, Daniel Drake wrote:
> > > On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu<baolu.lu@linux.intel.com>  wrote:
> > > > With respect, this is problematical. The parent and all subdevices share
> > > > a single translation entry. The DMA mask should be consistent.
> > > > 
> > > > Otherwise, for example, subdevice A has 64-bit DMA capability and uses
> > > > an identity domain for DMA translation. While subdevice B has 32-bit DMA
> > > > capability and is forced to switch to DMA domain. Subdevice A will be
> > > > impacted without any notification.
> > Looking closer, this problematic codepath may already be happening for VMD,
> > under intel_iommu_add_device(). Consider this function running for a VMD
> > subdevice, we hit:
> > 
> >      domain = iommu_get_domain_for_dev(dev);
> > 
> > I can't quite grasp the code flow here, but domain->type now always seems
> > to return the domain type of the real DMA device, which seems like pretty
> > reasonable behaviour.
> > 
> >      if (domain->type == IOMMU_DOMAIN_DMA) {
> > 
> > and as detailed in previous mails, the real VMD device seems to be in a DMA
> > domain by default, so we continue.
> > 
> >          if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY) {
> > 
> > Now we checked the default domain type of the subdevice. This seems rather
> > likely to return IDENTITY because that's effectively the default type...
> > 
> >              ret = iommu_request_dm_for_dev(dev);
> >              if (ret) {
> >                  dmar_remove_one_dev_info(dev);
> >                  dmar_domain->flags |= DOMAIN_FLAG_LOSE_CHILDREN;
> >                  domain_add_dev_info(si_domain, dev);
> >                  dev_info(dev,
> >                       "Device uses a private identity domain.\n");
> >              }
> >          }
> > 
> > and now we're doing the bad stuff that Lu pointed out: we only have one
> > mapping shared for all the subdevices, so if we end up changing it for one
> > subdevice, we're likely to be breaking another.
> 
> Yes. Agreed.
> 
> By the way, do all subdevices stay in a same iommu group?
> 
> Best regards,
> baolu


The VMD endpoint and all subdevices in the VMD domain are in the same
IOMMU group. The real dma device for VMD (the VMD endpoint) only
represents the DMA requester as determined by the PCIe source-id. The
VMD endpoint itself doesn't have a DMA engine so only the subdevices
matter for mapping.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-02-27 18:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19  3:21 [PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed Daniel Drake
2020-02-19  3:40 ` Lu Baolu
2020-02-20  3:36   ` Daniel Drake
2020-02-20 10:06     ` Daniel Drake
2020-02-20 11:58       ` Lu Baolu
2020-02-27 18:19         ` Derrick, Jonathan [this message]
2020-04-09  0:16       ` Derrick, Jonathan
2020-04-09  0:33         ` Derrick, Jonathan

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=199bcea7d614e57261ee34a02c8096e6ce725629.camel@intel.com \
    --to=jonathan.derrick@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=drake@endlessm.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux@endlessm.com \
    /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).