public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: baolu.lu@linux.intel.com, David Woodhouse <dwmw2@infradead.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Christoph Hellwig <hch@lst.de>,
	ashok.raj@intel.com, jacob.jun.pan@intel.com, alan.cox@intel.com,
	kevin.tian@intel.com, mika.westerberg@linux.intel.com,
	Ingo Molnar <mingo@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	pengfei.xu@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Jacob Pan <jacob.jun.pan@linux.intel.com>
Subject: Re: [PATCH v7 1/7] iommu/vt-d: Don't switch off swiotlb if use direct dma
Date: Sat, 24 Aug 2019 10:17:30 +0800	[thread overview]
Message-ID: <8fb96c3b-c535-6d90-e1e1-c635aec6f178@linux.intel.com> (raw)
In-Reply-To: <20190823083956.GB24194@8bytes.org>

Hi Joerg,

On 8/23/19 4:39 PM, Joerg Roedel wrote:
> On Fri, Aug 23, 2019 at 03:17:29PM +0800, Lu Baolu wrote:
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -4569,9 +4569,6 @@ static int __init platform_optin_force_iommu(void)
>>   		iommu_identity_mapping |= IDENTMAP_ALL;
>>   
>>   	dmar_disabled = 0;
>> -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB)
>> -	swiotlb = 0;
>> -#endif
>>   	no_iommu = 0;
>>   
>>   	return 1;
>> @@ -4710,9 +4707,6 @@ int __init intel_iommu_init(void)
>>   	}
>>   	up_write(&dmar_global_lock);
>>   
>> -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB)
>> -	swiotlb = 0;
>> -#endif
> 
> So this will cause the 64MB SWIOTLB aperture to be allocated even when
> there will never be an untrusted device in the system, right? I guess
> this will break some kdump setups as they need to resize their low
> memory allocations to make room for the aperture because of this
> patch-set.

Yes, you are right. I didn't consider the kdump case.

> 
> But I also don't see a way around this for now as untrusted devices are
> usually hotplugged and might not be present at boot. So we can't make
> the decision about the allocation at boot time.

If a system has any external port, through which an untrusted device
might be connected, the external port itself should be marked as an
untrusted device, and all devices beneath it just inherit this
attribution.

So during iommu driver initialization, we can easily know whether the
system has (or potentially has) untrusted devices by iterating the
device tree. I will add such check in the next version if no objections.

> 
> But this mechanism needs to be moved to the dma-iommu implementation at
> some point, and then we should allocate the bounce memory pages
> on-demand. We can easily do this in page-size chunks and map them
> together with iommu page-tables. This way we don't need to pre-allocate
> a large memory-chunk at boot.
> 
> Regards,
> 
> 	Joerg

Best regards,
Baolu


  reply	other threads:[~2019-08-24  2:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23  7:17 [PATCH v7 0/7] iommu: Bounce page for untrusted devices Lu Baolu
2019-08-23  7:17 ` [PATCH v7 1/7] iommu/vt-d: Don't switch off swiotlb if use direct dma Lu Baolu
2019-08-23  8:39   ` Joerg Roedel
2019-08-24  2:17     ` Lu Baolu [this message]
2019-08-30 10:31       ` Joerg Roedel
2019-08-23  7:17 ` [PATCH v7 2/7] PCI: Add dev_is_untrusted helper Lu Baolu
2019-08-23  7:17 ` [PATCH v7 3/7] swiotlb: Split size parameter to map/unmap APIs Lu Baolu
2019-08-23  7:17 ` [PATCH v7 4/7] swiotlb: Zero out bounce buffer for untrusted device Lu Baolu
2019-08-23  7:17 ` [PATCH v7 5/7] iommu/vt-d: Check whether device requires bounce buffer Lu Baolu
2019-08-23  7:17 ` [PATCH v7 6/7] iommu/vt-d: Add trace events for device dma map/unmap Lu Baolu
2019-08-23  7:17 ` [PATCH v7 7/7] iommu/vt-d: Use bounce buffer for untrusted devices Lu Baolu

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=8fb96c3b-c535-6d90-e1e1-c635aec6f178@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=alan.cox@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jgross@suse.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mingo@redhat.com \
    --cc=pengfei.xu@intel.com \
    --cc=robin.murphy@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=sstabellini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox