lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB527670BF3C50556D249598738C852@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 12 Aug 2024 00:19:56 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>, "Jason
 Gunthorpe" <jgg@...pe.ca>
CC: "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Jason
 Gunthorpe" <jgg@...dia.com>
Subject: RE: [PATCH v4 6/7] iommu/vt-d: Add support for static identity domain

> From: Baolu Lu <baolu.lu@...ux.intel.com>
> Sent: Saturday, August 10, 2024 4:02 PM
> 
> On 2024/8/9 16:29, Tian, Kevin wrote:
> >> From: Lu Baolu <baolu.lu@...ux.intel.com>
> >> Sent: Friday, August 9, 2024 1:55 PM
> >>
> >> +static int context_setup_pass_through(struct device *dev, u8 bus, u8
> devfn)
> >> +{
> >> +	struct device_domain_info *info = dev_iommu_priv_get(dev);
> >> +	struct intel_iommu *iommu = info->iommu;
> >> +	struct context_entry *context;
> >> +
> >> +	spin_lock(&iommu->lock);
> >> +	context = iommu_context_addr(iommu, bus, devfn, 1);
> >> +	if (!context) {
> >> +		spin_unlock(&iommu->lock);
> >> +		return -ENOMEM;
> >> +	}
> >> +
> >> +	if (context_present(context) && !context_copied(iommu, bus, devfn))
> >> {
> >> +		spin_unlock(&iommu->lock);
> >> +		return 0;
> >> +	}
> >
> > Is it a valid case to setup passthrough on a present entry?
> 
> It's valid but unnecessary.
> 
> Since the context is present, it indicates that the configuration has
> already been setup by a PCI aliased device. The iommu group mandates
> that all PCI aliased devices must be attached to the same iommu domain.
> Consequently, there's no need for additional configuration.
> 
> While it's feasible to remove this line of code due to the check in the
> pci_for_each_dma_alias() callback:
> 
> static int context_setup_pass_through_cb(struct pci_dev *pdev, u16
> alias, void *data)
> {
>          struct device *dev = data;
> 
>          if (dev != &pdev->dev)
>                  return 0;
> 
>          return context_setup_pass_through(dev, PCI_BUS_NUM(alias),
> alias & 0xff);
> }
> 
> But it's in the original code, I've retained it to prevent any potential
> regression.
> 

I failed to find the original code which is why I asked above question.

But now I got that you were talking about the check in
domain_context_mapping_one() which applied to the si domain before.

So,

Reviewed-by: Kevin Tian <kevin.tian@...el.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ