iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: FelixCui-oc <FelixCui-oc@zhaoxin.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"David Woodhouse" <dwmw2@infradead.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	"kbuild@lists.01.org" <kbuild@lists.01.org>
Cc: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
	CobeChen-oc <CobeChen-oc@zhaoxin.com>,
	Ashok Raj <ashok.raj@intel.com>
Subject: 答复: 答复: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI device in RMRR
Date: Wed, 2 Sep 2020 03:24:26 +0000	[thread overview]
Message-ID: <cfdd29a882d140e5aec2e8c3b77f4968@zhaoxin.com> (raw)
In-Reply-To: <7e5f2c33-c6c3-f344-9014-1f6a306c55aa@linux.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 6969 bytes --]

hi baolu,

> So you have a hidden device (invisible to host kernel). But you need to

>setup some identity mappings for this device, so that the firmware
>could keep working, right?

>The platform designs this by putting that range in the RMRR table and
>expecting the OS kernel to setup identity mappings during boot.

>Do I understand it right?


Yes. What you understand is correct.


Best regards

Felixcui-oc

________________________________
发件人: Lu Baolu <baolu.lu@linux.intel.com>
发送时间: 2020年9月2日 10:32:36
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org; David Woodhouse; Dan Carpenter; kbuild@lists.01.org
抄送: baolu.lu@linux.intel.com; CobeChen-oc; RaymondPang-oc; Tony W Wang-oc; Ashok Raj
主题: Re: 答复: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI device in RMRR

On 9/1/20 5:13 PM, FelixCui-oc wrote:
> hi  baolu ,
>
>                     These ACPI devices can be retrieved from the kernel
> and there is no bound device driver .

So you have a hidden device (invisible to host kernel). But you need to
setup some identity mappings for this device, so that the firmware
could keep working, right?

The platform designs this by putting that range in the RMRR table and
expecting the OS kernel to setup identity mappings during boot.

Do I understand it right?

Best regards,
baolu

>
>
> Best regards
>
> Felixcui-oc
>
> ------------------------------------------------------------------------
> *发件人:* Lu Baolu <baolu.lu@linux.intel.com>
> *发送时间:* 2020年9月1日 14:12:34
> *收件人:* FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org; David Woodhouse; Dan Carpenter;
> kbuild@lists.01.org
> *抄送:* baolu.lu@linux.intel.com; CobeChen-oc; RaymondPang-oc; Tony W
> Wang-oc
> *主题:* Re: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI
> device in RMRR
> Hi Felix,
>
> On 8/27/20 6:02 PM, FelixCuioc wrote:
>> After acpi device in RMRR is detected,it is necessary
>> to establish a mapping for these devices.
>> In acpi_device_create_direct_mappings(),create a mapping
>> for the acpi device in RMRR.
>> Add a helper to achieve the acpi namespace device can
>> access the RMRR region.
>
> Are those ACPI devices visible to kernel? If so, any device driver bound
> for it?
>
> Best regards,
> baolu
>
>>
>> Signed-off-by: FelixCuioc <FelixCui-oc@zhaoxin.com>
>> ---
>>   drivers/iommu/intel/iommu.c | 29 +++++++++++++++++++++++++++++
>>   drivers/iommu/iommu.c       |  6 ++++++
>>   include/linux/iommu.h       |  3 +++
>>   3 files changed, 38 insertions(+)
>>
>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>> index 208a91605288..51d7a5b18f41 100644
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -4799,6 +4799,21 @@ static int __init platform_optin_force_iommu(void)
>>        return 1;
>>   }
>>
>> +static int acpi_device_create_direct_mappings(struct device *pn_dev, struct device *acpi_device)
>> +{
>> +     struct iommu_group *group;
>> +
>> +     acpi_device->bus->iommu_ops = &intel_iommu_ops;
>> +     group = iommu_group_get(pn_dev);
>> +     if (!group) {
>> +             pr_warn("ACPI name space devices create direct mappings wrong!\n");
>> +             return -EINVAL;
>> +     }
>> +     __acpi_device_create_direct_mappings(group, acpi_device);
>> +
>> +     return 0;
>> +}
>> +
>>   static int __init probe_acpi_namespace_devices(void)
>>   {
>>        struct dmar_drhd_unit *drhd;
>> @@ -4813,6 +4828,7 @@ static int __init probe_acpi_namespace_devices(void)
>>                        struct acpi_device_physical_node *pn;
>>                        struct iommu_group *group;
>>                        struct acpi_device *adev;
>> +                     struct device *pn_dev = NULL;
>>
>>                        if (dev->bus != &acpi_bus_type)
>>                                continue;
>> @@ -4823,6 +4839,7 @@ static int __init probe_acpi_namespace_devices(void)
>>                                            &adev->physical_node_list, node) {
>>                                group = iommu_group_get(pn->dev);
>>                                if (group) {
>> +                                     pn_dev = pn->dev;
>>                                        iommu_group_put(group);
>>                                        continue;
>>                                }
>> @@ -4831,7 +4848,19 @@ static int __init probe_acpi_namespace_devices(void)
>>                                ret = iommu_probe_device(pn->dev);
>>                                if (ret)
>>                                        break;
>> +                             pn_dev = pn->dev;
>> +                     }
>> +                     if (!pn_dev) {
>> +                             dev->bus->iommu_ops = &intel_iommu_ops;
>> +                             ret = iommu_probe_device(dev);
>> +                             if (ret) {
>> +                                     pr_err("acpi_device probe fail! ret:%d\n", ret);
>> +                                     goto unlock;
>> +                             }
>> +                             goto unlock;
>>                        }
>> +                     ret = acpi_device_create_direct_mappings(pn_dev, dev);
>> +unlock:
>>                        mutex_unlock(&adev->physical_node_lock);
>>
>>                        if (ret)
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 609bd25bf154..4f714a2d5ef7 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -779,6 +779,12 @@ static bool iommu_is_attach_deferred(struct iommu_domain *domain,
>>        return false;
>>   }
>>
>> +void  __acpi_device_create_direct_mappings(struct iommu_group *group, struct device *acpi_device)
>> +{
>> +     iommu_create_device_direct_mappings(group, acpi_device);
>> +}
>> +EXPORT_SYMBOL_GPL(__acpi_device_create_direct_mappings);
>> +
>>   /**
>>    * iommu_group_add_device - add a device to an iommu group
>>    * @group: the group into which to add the device (reference should be held)
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index fee209efb756..9be134775886 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -514,6 +514,9 @@ extern void iommu_domain_window_disable(struct iommu_domain *domain, u32 wnd_nr)
>>   extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
>>                              unsigned long iova, int flags);
>>
>> +extern void __acpi_device_create_direct_mappings(struct iommu_group *group,
>> +                                             struct device *acpi_device);
>> +
>>   static inline void iommu_flush_tlb_all(struct iommu_domain *domain)
>>   {
>>        if (domain->ops->flush_iotlb_all)
>>

[-- Attachment #1.2: Type: text/html, Size: 18315 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-09-02  3:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 10:02 [PATCH v3 0/2] Add support for ACPI device in RMRR FelixCuioc
2020-08-27 10:02 ` [PATCH v3 1/2] iommu/vt-d:Add support for detecting " FelixCuioc
2020-09-01  6:05   ` Lu Baolu
2020-09-01  7:53     ` 答复: " FelixCui-oc
2020-09-02  1:48       ` FelixCui-oc
2020-08-27 10:02 ` [PATCH v3 2/2] iommu/vt-d:Add support for probing " FelixCuioc
2020-09-01  6:12   ` Lu Baolu
2020-09-01  9:13     ` 答复: " FelixCui-oc
2020-09-02  2:32       ` Lu Baolu
2020-09-02  3:24         ` FelixCui-oc [this message]
2020-09-03  7:22           ` 答复: " Lu Baolu
2020-09-04  5:42             ` 答复: " FelixCui-oc

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=cfdd29a882d140e5aec2e8c3b77f4968@zhaoxin.com \
    --to=felixcui-oc@zhaoxin.com \
    --cc=CobeChen-oc@zhaoxin.com \
    --cc=TonyWWang-oc@zhaoxin.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kbuild@lists.01.org \
    --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 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).