From: Lu Baolu <baolu.lu@linux.intel.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
LKML <linux-kernel@vger.kernel.org>,
iommu@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>,
Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH v6 01/10] iommu/vt-d: Enlightened PASID allocation
Date: Fri, 25 Oct 2019 09:42:43 +0800 [thread overview]
Message-ID: <d5f68e37-adba-0804-904b-660e8e812ece@linux.intel.com> (raw)
In-Reply-To: <20191023141126.38bc1644@jacob-builder>
Hi,
On 10/24/19 5:11 AM, Jacob Pan wrote:
> On Wed, 23 Oct 2019 10:55:23 -0700
> Jacob Pan <jacob.jun.pan@linux.intel.com> wrote:
>
>>>> Do you have to check this everytime? every dmar_readq is going to
>>>> trap to the other side ...
>>>
>>> Yes. We don't need to check it every time. Check once and save the
>>> result during boot is enough.
>>>
>>> How about below incremental change?
>>>
>> Below is good but I was thinking to include vccap in struct
>> intel_iommu{} where cap and ecaps reside. i.e.
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
>> index 14b87ae2916a..e2cf25c9c956 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -528,6 +528,7 @@ struct intel_iommu {
>> u64 reg_size; /* size of hw register set */
>> u64 cap;
>> u64 ecap;
>> + u64 vccap;
>>
>> Also, we can use a static branch here.
>>
> On a second thought, we cannot use static(branch) here in that we
> cannot assume there is only one vIOMMU all the time. Have to cache the
> vccap per iommu.
intel_iommu is a per iommu structure, right? Or I missed anything?
>
>>> diff --git a/drivers/iommu/intel-pasid.c
>>> b/drivers/iommu/intel-pasid.c index ff7e877b7a4d..c15d9d7e1e73
>>> 100644 --- a/drivers/iommu/intel-pasid.c
>>> +++ b/drivers/iommu/intel-pasid.c
>>> @@ -29,22 +29,29 @@ u32 intel_pasid_max_id = PASID_MAX;
>>>
> [Jacob Pan]
>
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: baolu.lu@linux.intel.com, "Raj, Ashok" <ashok.raj@intel.com>,
iommu@lists.linux-foundation.org,
LKML <linux-kernel@vger.kernel.org>,
Joerg Roedel <joro@8bytes.org>,
David Woodhouse <dwmw2@infradead.org>,
Alex Williamson <alex.williamson@redhat.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Yi Liu <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>,
Christoph Hellwig <hch@infradead.org>,
Jonathan Cameron <jic23@kernel.org>,
Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v6 01/10] iommu/vt-d: Enlightened PASID allocation
Date: Fri, 25 Oct 2019 09:42:43 +0800 [thread overview]
Message-ID: <d5f68e37-adba-0804-904b-660e8e812ece@linux.intel.com> (raw)
In-Reply-To: <20191023141126.38bc1644@jacob-builder>
Hi,
On 10/24/19 5:11 AM, Jacob Pan wrote:
> On Wed, 23 Oct 2019 10:55:23 -0700
> Jacob Pan <jacob.jun.pan@linux.intel.com> wrote:
>
>>>> Do you have to check this everytime? every dmar_readq is going to
>>>> trap to the other side ...
>>>
>>> Yes. We don't need to check it every time. Check once and save the
>>> result during boot is enough.
>>>
>>> How about below incremental change?
>>>
>> Below is good but I was thinking to include vccap in struct
>> intel_iommu{} where cap and ecaps reside. i.e.
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
>> index 14b87ae2916a..e2cf25c9c956 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -528,6 +528,7 @@ struct intel_iommu {
>> u64 reg_size; /* size of hw register set */
>> u64 cap;
>> u64 ecap;
>> + u64 vccap;
>>
>> Also, we can use a static branch here.
>>
> On a second thought, we cannot use static(branch) here in that we
> cannot assume there is only one vIOMMU all the time. Have to cache the
> vccap per iommu.
intel_iommu is a per iommu structure, right? Or I missed anything?
>
>>> diff --git a/drivers/iommu/intel-pasid.c
>>> b/drivers/iommu/intel-pasid.c index ff7e877b7a4d..c15d9d7e1e73
>>> 100644 --- a/drivers/iommu/intel-pasid.c
>>> +++ b/drivers/iommu/intel-pasid.c
>>> @@ -29,22 +29,29 @@ u32 intel_pasid_max_id = PASID_MAX;
>>>
> [Jacob Pan]
>
Best regards,
baolu
next prev parent reply other threads:[~2019-10-25 1:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 23:53 [PATCH v6 00/10] Nested Shared Virtual Address (SVA) VT-d support Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 01/10] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-23 0:45 ` Raj, Ashok
2019-10-23 0:45 ` Raj, Ashok
2019-10-23 1:53 ` Lu Baolu
2019-10-23 1:53 ` Lu Baolu
2019-10-23 17:55 ` Jacob Pan
2019-10-23 17:55 ` Jacob Pan
2019-10-23 21:11 ` Jacob Pan
2019-10-23 21:11 ` Jacob Pan
2019-10-25 1:42 ` Lu Baolu [this message]
2019-10-25 1:42 ` Lu Baolu
2019-10-25 1:39 ` Lu Baolu
2019-10-25 1:39 ` Lu Baolu
2019-10-22 23:53 ` [PATCH v6 02/10] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-23 0:51 ` Raj, Ashok
2019-10-23 0:51 ` Raj, Ashok
2019-10-23 2:21 ` Lu Baolu
2019-10-23 2:21 ` Lu Baolu
2019-10-23 23:01 ` Jacob Pan
2019-10-23 23:01 ` Jacob Pan
2019-10-25 1:44 ` Lu Baolu
2019-10-25 1:44 ` Lu Baolu
2019-10-23 4:04 ` Jacob Pan
2019-10-23 4:04 ` Jacob Pan
2019-10-23 23:04 ` Jacob Pan
2019-10-23 23:04 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 03/10] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-23 0:58 ` Raj, Ashok
2019-10-23 0:58 ` Raj, Ashok
2019-10-23 4:19 ` Jacob Pan
2019-10-23 4:19 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 04/10] iommu/vt-d: Move domain helper to header Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 05/10] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 06/10] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 07/10] iommu/vt-d: Misc macro clean up for SVM Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 08/10] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 09/10] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-22 23:53 ` [PATCH v6 10/10] iommu/vt-d: Add svm/sva invalidate function Jacob Pan
2019-10-22 23:53 ` Jacob Pan
2019-10-23 0:27 ` [PATCH v6 00/10] Nested Shared Virtual Address (SVA) VT-d support Raj, Ashok
2019-10-23 0:27 ` Raj, Ashok
2019-10-23 13:46 ` Jacob Pan
2019-10-23 13:46 ` Jacob Pan
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=d5f68e37-adba-0804-904b-660e8e812ece@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.com \
--cc=jic23@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.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.