All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Eric Badger <ebadger@purestorage.com>
Cc: baolu.lu@linux.intel.com, David Woodhouse <dwmw2@infradead.org>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"open list:INTEL IOMMU (VT-d)" <iommu@lists.linux.dev>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iommu/vt-d: Check for non-NULL domain on device release
Date: Wed, 31 Jan 2024 15:10:53 +0800	[thread overview]
Message-ID: <7455b538-e934-4377-9ab5-004ee991b3d2@linux.intel.com> (raw)
In-Reply-To: <20240116152215.GE50608@ziepe.ca>

On 2024/1/16 23:22, Jason Gunthorpe wrote:
>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>> index 6fb5f6fceea1..26e450259889 100644
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -3750,7 +3750,6 @@ static void domain_context_clear(struct device_domain_info *info)
>>   static void dmar_remove_one_dev_info(struct device *dev)
>>   {
>>   	struct device_domain_info *info = dev_iommu_priv_get(dev);
>> -	struct dmar_domain *domain = info->domain;
>>   	struct intel_iommu *iommu = info->iommu;
>>   	unsigned long flags;
>>   
>> @@ -3763,11 +3762,14 @@ static void dmar_remove_one_dev_info(struct device *dev)
>>   		domain_context_clear(info);
>>   	}
>>   
>> -	spin_lock_irqsave(&domain->lock, flags);
>> +	if (!info->domain)
>> +		return;
>> +
>> +	spin_lock_irqsave(&info->domain->lock, flags);
>>   	list_del(&info->link);
>> -	spin_unlock_irqrestore(&domain->lock, flags);
>> +	spin_unlock_irqrestore(&info->domain->lock, flags);
>>   
>> -	domain_detach_iommu(domain, iommu);
>> +	domain_detach_iommu(info->domain, iommu);
>>   	info->domain = NULL;
>>   }
> This function is almost a copy of device_block_translation(), with
> some bugs added :\
> 
> Lu can they be made the same? It seems to me BLOCKED could always
> clear the domain context, even in scalable mode?

Yes. A part of dmar_remove_one_dev_info() is duplicated with
device_block_translation().

> 
> Anyhow, my suggestion is more like:

I like this suggestion.

Currently, the device_release callback for an iommu driver does the
following:

a) Silent IOMMU DMA translation. This is done by detaching the existing
    domain from the IOMMU and bringing the IOMMU into a blocking state
    (some drivers might be in identity state);
b) Releases the resources allocated in the probe callback and restores
    the device to its previous state before the probe.

 From my understanding of your suggestion, we should move a) out of the
release callback and make it a special domain, which could be a blocking
domain or identity domain, depending on the iommu hardware.

In the end, the release_device callback of an iommu driver should focus
on the opposite operation of device_probe. This makes the concept
clearer.

Best regards,
baolu

  parent reply	other threads:[~2024-01-31  7:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-13 18:17 [PATCH] iommu/vt-d: Check for non-NULL domain on device release Eric Badger
2024-01-16 15:22 ` Jason Gunthorpe
2024-01-16 23:15   ` Eric Badger
2024-01-17  1:57   ` Robin Murphy
2024-01-17  2:20     ` Jason Gunthorpe
2024-01-31  7:10   ` Baolu Lu [this message]
2024-02-21 15:40     ` Jason Gunthorpe
2024-02-22 11:53       ` Baolu Lu

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=7455b538-e934-4377-9ab5-004ee991b3d2@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=ebadger@purestorage.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.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.