答复: [PATCH v3 0/2] Add support for ACPI device in RMRR

2020-10-13 Thread FelixCui-oc
hi baolu,


>By the way, I guess the problem you are facing can still be handled well
>under current RMRR mechanism by simple putting the device in the
>ACPI/ANDD table. It's worth trying.


I understand what you mean is that  just put the device in the ANDD table and 
don't use RMRR, right?

But this can't solve my problem. Can you explain it in detail how to solve my 
problem?


In addition, the latest VT-D spec still has support for the use of acpi device 
under RMRR and ANDD.

From the perpective of supporting spec , the driver should support the case we 
submitted.


Best regards

Felixcui-oc



发件人: Lu Baolu 
发送时间: 2020年10月12日 10:31:40
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: baolu...@linux.intel.com; CobeChen-oc; RaymondPang-oc; Tony W Wang-oc
主题: Re: [PATCH v3 0/2] Add support for ACPI device in RMRR

Hi Felix,

On 10/10/20 4:02 PM, FelixCuioc wrote:
> BIOS allocate reserved memory ranges that may be DMA targets.
> BIOS may report each such reserved memory region through the
> RMRR structures,along with the devices that requires access to
> the specified reserved memory region.
>
> The purpose of this series is to achieve ACPI device in RMRR
> access reserved memory.Therefore,it is necessary to increase
> the analysis of acpi device in RMRR and establish a mapping
> for this device.
>
> The first patch adds interfaces for detecting ACPI device
> in RMRR and in order to distinguish it from pci device,
> some interface functions are modified.
>
> The second patch adds support for probing ACPI device in RMRR.
> In probe_acpi_namespace_devices(),add support for direct mapping
> of ACPI device and add support for physical node of acpi device
> to be NULL.

Thanks for your patches. As I explained in the previous reply, RMRRs
were added as work around for certain legacy device and we have been
working hard to fix those legacy devices so that RMRR are no longer
needed. Any new use case of RMRR is not encouraged.

By the way, I guess the problem you are facing can still be handled well
under current RMRR mechanism by simple putting the device in the
ACPI/ANDD table. It's worth trying.

Best regards,
baolu

>
> v2->v3:
> - Add the blank line between functions.
> - Make dmar_acpi_insert_dev_scope() bool,change the 1/0 to true/false
>   and add a comment explaining.
> - Delete unused initialization.
> - if dmar_acpi_insert_dev_scope() always returns zero,will not
>   call dmar_rmrr_add_acpi_dev().
> - Use a proper error code.
> - Use if(!pdev).
> - Use goto unlock instead of mutex_unlock().
>
>
> FelixCuioc (2):
>iommu/vt-d:Add support for detecting ACPI device in RMRR
>iommu/vt-d:Add support for probing ACPI device in RMRR
>
>   drivers/iommu/intel/dmar.c  | 76 +
>   drivers/iommu/intel/iommu.c | 52 -
>   drivers/iommu/iommu.c   |  6 +++
>   include/linux/dmar.h| 12 +-
>   include/linux/iommu.h   |  2 +
>   5 files changed, 113 insertions(+), 35 deletions(-)
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

答复: 答复: 答复: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI device in RMRR

2020-09-03 Thread FelixCui-oc
hi baolu,

   We run this on zhaoxin X86 paltform.

   There are some MCUS on our platforms that read and write data to 
the system memory.

During this process, the MCU is invisible to the host kernel. And the MCU needs 
to report through ACPI_NAMESPACE_DEVICE in RMRR.


Best regards

Felixcui-oc


发件人: Lu Baolu 
发送时间: 2020年9月3日 15:22:14
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: baolu...@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

Hi Felix,

On 9/2/20 11:24 AM, FelixCui-oc wrote:
> 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.

This appears to be a new usage model of RMRR. I need to discuss this
with the VT-d spec maintainer. Do you mind telling which platform are
you going to run this on? What is the motivation of creating such hidden
device?

Basically, RMRRs were added as work around for certain legacy device and
we have been working hard to fix those legacy devices so that RMRR are
no longer needed.

Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

答复: 答复: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI device in RMRR

2020-09-01 Thread FelixCui-oc
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 
发送时间: 2020年9月2日 10:32:36
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: baolu...@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 
> *发送时间:* 2020年9月1日 14:12:34
> *收件人:* FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org;
> linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter;
> kbu...@lists.01.org
> *抄送:* baolu...@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 
>> ---
>>   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);
>>  

答复: [PATCH v3 1/2] iommu/vt-d:Add support for detecting ACPI device in RMRR

2020-09-01 Thread FelixCui-oc
hi  baolu ,

   Add pr_info(), there will be a problem.

   dmar_acpi_bus_add_dev() will call 
dmar_acpi_insert_dev_scope() twice. So it will  print two identical  logs. This 
is similar to dmar_pci_bus_add_dev(). What do you think?



  Add pr_warn(), No problem.


Best regards

Felixcui-oc




发件人: FelixCui-oc
发送时间: 2020年9月1日 15:53:47
收件人: Lu Baolu; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: CobeChen-oc; RaymondPang-oc; Tony W Wang-oc
主题: 答复: [PATCH v3 1/2] iommu/vt-d:Add support for detecting ACPI device in RMRR


hi  baolu,

  The function dmar_rmrr_add_acpi_dev() is defined in 
intel/iommu.c because struct dmar_rmrr_unit {} is defined in intel/iommu.c.

  And dmar_parse_one_rmrr()  is also defined here, so we think 
it should be defined in iommu.c.


Best regards
Felixcui-oc


发件人: Lu Baolu 
发送时间: 2020年9月1日 14:05
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: baolu...@linux.intel.com; CobeChen-oc; RaymondPang-oc; Tony W Wang-oc
主题: Re: [PATCH v3 1/2] iommu/vt-d:Add support for detecting ACPI device in RMRR

Hi Felix,

On 8/27/20 6:02 PM, FelixCuioc wrote:
> Some ACPI devices need to issue dma requests to access
> the reserved memory area.BIOS uses the device scope type
> ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
> This patch add support for detecting ACPI devices in RMRR.
>
> Signed-off-by: FelixCuioc 
> ---
>   drivers/iommu/intel/dmar.c  | 76 +
>   drivers/iommu/intel/iommu.c | 23 ++-
>   include/linux/dmar.h| 12 +-
>   3 files changed, 76 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index 93e6345f3414..f6691c36bd3f 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -215,7 +215,7 @@ static bool dmar_match_pci_path(struct 
> dmar_pci_notify_info *info, int bus,
>   }
>
>   /* Return: > 0 if match found, 0 if no match found, < 0 if error happens */
> -int dmar_insert_dev_scope(struct dmar_pci_notify_info *info,
> +int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info,
>  void *start, void*end, u16 segment,
>  struct dmar_dev_scope *devices,
>  int devices_cnt)
> @@ -304,7 +304,7 @@ static int dmar_pci_bus_add_dev(struct 
> dmar_pci_notify_info *info)
>
>drhd = container_of(dmaru->hdr,
>struct acpi_dmar_hardware_unit, header);
> - ret = dmar_insert_dev_scope(info, (void *)(drhd + 1),
> + ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1),
>((void *)drhd) + drhd->header.length,
>dmaru->segment,
>dmaru->devices, dmaru->devices_cnt);
> @@ -697,47 +697,59 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev)
>return dmaru;
>   }
>
> -static void __init dmar_acpi_insert_dev_scope(u8 device_number,
> -   struct acpi_device *adev)
> +/* Return: > 0 if match found, 0 if no match found */
> +bool dmar_acpi_insert_dev_scope(u8 device_number,
> + struct acpi_device *adev,
> + void *start, void *end,
> + struct dmar_dev_scope *devices,
> + int devices_cnt)
>   {
> - struct dmar_drhd_unit *dmaru;
> - struct acpi_dmar_hardware_unit *drhd;
>struct acpi_dmar_device_scope *scope;
>struct device *tmp;
>int i;
>struct acpi_dmar_pci_path *path;
>
> + for (; start < end; start += scope->length) {
> + scope = start;
> + if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
> + continue;
> + if (scope->enumeration_id != device_number)
> + continue;
> + path = (void *)(scope + 1);
> + for_each_dev_scope(devices, devices_cnt, i, tmp)
> + if (tmp == NULL) {
> + devices[i].bus = scope->bus;
> + devices[i].devfn = PCI_DEVFN(path->device, 
> path->function);
> + rcu_assign_pointer(devices[i].dev,
> +get_device(&adev->dev));
> +

答复: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI device in RMRR

2020-09-01 Thread FelixCui-oc
hi  baolu ,

   These ACPI devices can be retrieved from the kernel and 
there is no bound device driver .


Best regards

Felixcui-oc


发件人: Lu Baolu 
发送时间: 2020年9月1日 14:12:34
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: baolu...@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 
> ---
>   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/

答复: [PATCH v3 1/2] iommu/vt-d:Add support for detecting ACPI device in RMRR

2020-09-01 Thread FelixCui-oc
hi  baolu,

  The function dmar_rmrr_add_acpi_dev() is defined in 
intel/iommu.c because struct dmar_rmrr_unit {} is defined in intel/iommu.c.

  And dmar_parse_one_rmrr()  is also defined here, so we think 
it should be defined in iommu.c.


Best regards
Felixcui-oc


发件人: Lu Baolu 
发送时间: 2020年9月1日 14:05
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org; 
linux-ker...@vger.kernel.org; David Woodhouse; Dan Carpenter; 
kbu...@lists.01.org
抄送: baolu...@linux.intel.com; CobeChen-oc; RaymondPang-oc; Tony W Wang-oc
主题: Re: [PATCH v3 1/2] iommu/vt-d:Add support for detecting ACPI device in RMRR

Hi Felix,

On 8/27/20 6:02 PM, FelixCuioc wrote:
> Some ACPI devices need to issue dma requests to access
> the reserved memory area.BIOS uses the device scope type
> ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
> This patch add support for detecting ACPI devices in RMRR.
>
> Signed-off-by: FelixCuioc 
> ---
>   drivers/iommu/intel/dmar.c  | 76 +
>   drivers/iommu/intel/iommu.c | 23 ++-
>   include/linux/dmar.h| 12 +-
>   3 files changed, 76 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index 93e6345f3414..f6691c36bd3f 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -215,7 +215,7 @@ static bool dmar_match_pci_path(struct 
> dmar_pci_notify_info *info, int bus,
>   }
>
>   /* Return: > 0 if match found, 0 if no match found, < 0 if error happens */
> -int dmar_insert_dev_scope(struct dmar_pci_notify_info *info,
> +int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info,
>  void *start, void*end, u16 segment,
>  struct dmar_dev_scope *devices,
>  int devices_cnt)
> @@ -304,7 +304,7 @@ static int dmar_pci_bus_add_dev(struct 
> dmar_pci_notify_info *info)
>
>drhd = container_of(dmaru->hdr,
>struct acpi_dmar_hardware_unit, header);
> - ret = dmar_insert_dev_scope(info, (void *)(drhd + 1),
> + ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1),
>((void *)drhd) + drhd->header.length,
>dmaru->segment,
>dmaru->devices, dmaru->devices_cnt);
> @@ -697,47 +697,59 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev)
>return dmaru;
>   }
>
> -static void __init dmar_acpi_insert_dev_scope(u8 device_number,
> -   struct acpi_device *adev)
> +/* Return: > 0 if match found, 0 if no match found */
> +bool dmar_acpi_insert_dev_scope(u8 device_number,
> + struct acpi_device *adev,
> + void *start, void *end,
> + struct dmar_dev_scope *devices,
> + int devices_cnt)
>   {
> - struct dmar_drhd_unit *dmaru;
> - struct acpi_dmar_hardware_unit *drhd;
>struct acpi_dmar_device_scope *scope;
>struct device *tmp;
>int i;
>struct acpi_dmar_pci_path *path;
>
> + for (; start < end; start += scope->length) {
> + scope = start;
> + if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
> + continue;
> + if (scope->enumeration_id != device_number)
> + continue;
> + path = (void *)(scope + 1);
> + for_each_dev_scope(devices, devices_cnt, i, tmp)
> + if (tmp == NULL) {
> + devices[i].bus = scope->bus;
> + devices[i].devfn = PCI_DEVFN(path->device, 
> path->function);
> + rcu_assign_pointer(devices[i].dev,
> +get_device(&adev->dev));
> + return true;
> + }
> + WARN_ON(i >= devices_cnt);
> + }
> + return false;
> +}
> +
> +static int dmar_acpi_bus_add_dev(u8 device_number, struct acpi_device *adev)
> +{
> + struct dmar_drhd_unit *dmaru;
> + struct acpi_dmar_hardware_unit *drhd;
> + int ret;
> +
>for_each_drhd_unit(dmaru) {
>drhd = container_of(dmaru->hdr,
>struct acpi_dmar_hardware_unit,
>header);
> + ret = dmar_acpi_insert_dev_scope(device_number, adev, (void 
> *)(drhd+1),
> +  

答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-08 Thread FelixCui-oc
Hi baolu,
The attachment is the new patch.
If you have any questions, you can contact me at any time.
Thanks.

Best regards
Felix cui-oc




-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月7日 16:08
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI 
device in RMRR

Hi,

On 2020/8/7 11:29, FelixCui-oc wrote:
> Hi baolu,
>   I understand what you mean is that you want to put the 
> following processing code in the acpi_device_create_direct_mappings() into 
> the probe_acpi_namespace_devices() ,right?
>   If you mean it , I think it's OK.

Yes. If the acpi device has companion physical devices, then probe the 
companion devices; otherwise, probe the acpi device instead. Also, let's put 
detecting and probing acpi devices in different patches so that they could be 
easier for reviewing.

Best regards,
baolu

> 
>   if (pn_dev == NULL) {
>   acpi_device->bus->iommu_ops = &intel_iommu_ops;
>   ret = iommu_probe_device(acpi_device);
>   if (ret) {
>   pr_err("acpi_device probe fail! ret:%d\n", ret);
>   return ret;
>   }
>   return 0;
>   }
> 
> Best regards
> Felix cui-oc
> 
> 
> 
>   
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月7日 9:08
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for 
> ACPI device in RMRR
> 
> Hi Felix,
> 
> On 2020/8/6 14:51, FelixCui-oc wrote:
>> Hi  baolu,
>>  >Sure. Before that, let me sync my understanding with you. You 
>> have an acpi namespace device in ANDD table, it also shows up in the device 
>> scope of a RMRR.
>>  >Current code doesn't enumerate that device for the RMRR, hence 
>> iommu_create_device_direct_mappings() doesn't work for this device.
>>
>>  >At the same time, probe_acpi_namespace_devices() doesn't work 
>> for this device, hence you want to add a home-made
>>  >acpi_device_create_direct_mappings() helper.
>>
>>  Your understanding is right.
>>  But there is a problem that even if the namespace device in 
>> rmrr is enumerated in the code, probe_acpi_namespace_devices() also doesn't 
>> work for this device.
>>  This is because the dev parameter of the 
>> iommu_create_device_direct_mappings() is not the namespace device in RMRR.
>>  The actual parameter passed in is the namespace device's 
>> physical node device.
>>  In iommu_create_device_direct_mappings(), the physical node 
>> device passed in cannot match the namespace device in rmrr->device[],right?
>>  We need acpi_device_create_direct_mappings() helper ?
>>
>>  In addition, adev->physical_node_list is related to the __HID 
>> of namespace device reported by the bios.
>>  For example, if the __HID reported by the bios belongs to 
>> acpi_pnp_device_ids[], adev->physical_node_list has no devices.
>>  So in acpi_device_create_direct_mappings(), I added the case 
>> that adev->physical_node_list is empty.
> 
> Got you. Thanks!
> 
> Have you ever tried to have probe_acpi_namespace_devices() handle the case of 
> empty adev->physical_node_list at the same time?
> 
> Best regards,
> baolu
> 
>>
>>
>> Best regards
>> Felix cui
>>
>>
>>
>>
>> -邮件原件-
>> 发件人: Lu Baolu 
>> 发送时间: 2020年8月6日 10:36
>> 收件人: FelixCui-oc ; Joerg Roedel 
>> ; iommu@lists.linux-foundation.org; 
>> linux-ker...@vger.kernel.org; David Woodhouse 
>> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
>> ; CobeChen-oc 
>> 主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI 
>> device in RMRR
>>
>> Hi Felix,
>>
>> On 8/5/20 3:37 PM, FelixCui-oc wrote:
>>> Hi baolu,
>>> Let me talk about why acpi_device_create_direct_mappings() is 
>>> needed and please tell me if there is an error.
>>
>> Sure. Before that, let me sync my understanding with you. You have an acpi 
>> namespace device in ANDD table, it also sh

答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-06 Thread FelixCui-oc
Hi baolu,
I understand what you mean is that you want to put the 
following processing code in the acpi_device_create_direct_mappings() into the 
probe_acpi_namespace_devices() ,right?
If you mean it , I think it's OK. 

if (pn_dev == NULL) {
acpi_device->bus->iommu_ops = &intel_iommu_ops;
ret = iommu_probe_device(acpi_device);
if (ret) {
pr_err("acpi_device probe fail! ret:%d\n", ret);
return ret;
}
return 0;
}

Best regards
Felix cui-oc





-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月7日 9:08
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device 
in RMRR

Hi Felix,

On 2020/8/6 14:51, FelixCui-oc wrote:
> Hi  baolu,
>   >Sure. Before that, let me sync my understanding with you. You 
> have an acpi namespace device in ANDD table, it also shows up in the device 
> scope of a RMRR.
>   >Current code doesn't enumerate that device for the RMRR, hence 
> iommu_create_device_direct_mappings() doesn't work for this device.
> 
>   >At the same time, probe_acpi_namespace_devices() doesn't work 
> for this device, hence you want to add a home-made
>   >acpi_device_create_direct_mappings() helper.
> 
>   Your understanding is right.
>   But there is a problem that even if the namespace device in 
> rmrr is enumerated in the code, probe_acpi_namespace_devices() also doesn't 
> work for this device.
>   This is because the dev parameter of the 
> iommu_create_device_direct_mappings() is not the namespace device in RMRR.
>   The actual parameter passed in is the namespace device's 
> physical node device.
>   In iommu_create_device_direct_mappings(), the physical node 
> device passed in cannot match the namespace device in rmrr->device[],right?
>   We need acpi_device_create_direct_mappings() helper ?
> 
>   In addition, adev->physical_node_list is related to the __HID 
> of namespace device reported by the bios.
>   For example, if the __HID reported by the bios belongs to 
> acpi_pnp_device_ids[], adev->physical_node_list has no devices.
>   So in acpi_device_create_direct_mappings(), I added the case 
> that adev->physical_node_list is empty.

Got you. Thanks!

Have you ever tried to have probe_acpi_namespace_devices() handle the case of 
empty adev->physical_node_list at the same time?

Best regards,
baolu

> 
> 
> Best regards
> Felix cui
> 
> 
>   
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月6日 10:36
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI 
> device in RMRR
> 
> Hi Felix,
> 
> On 8/5/20 3:37 PM, FelixCui-oc wrote:
>> Hi baolu,
>>  Let me talk about why acpi_device_create_direct_mappings() is 
>> needed and please tell me if there is an error.
> 
> Sure. Before that, let me sync my understanding with you. You have an acpi 
> namespace device in ANDD table, it also shows up in the device scope of a 
> RMRR. Current code doesn't enumerate that device for the RMRR, hence 
> iommu_create_device_direct_mappings() doesn't work for this device.
> 
> At the same time, probe_acpi_namespace_devices() doesn't work for this 
> device, hence you want to add a home-made
> acpi_device_create_direct_mappings() helper.
> 
> Did I get it right?
> 
>>  In the probe_acpi_namespace_devices() function, only the device 
>> in the addev->physical_node_list is probed,
>>  but we need to establish identity mapping for the namespace 
>> device in RMRR. These are two different devices.
> 
> The namespace device has been probed and put in one drhd's device list.
> Hence, it should be processed by probe_acpi_namespace_devices(). So the 
> question is why there are no devices in addev->physical_node_list?
> 
>>  Therefore, the namespace device in RMRR is not mapped in 
>> probe_acpi_namespace_devices().
>>  acpi_device_create_direct_mappings() is to create direct 
>> mappings for namespace devices in RMRR.
> 
> Best regards,
> baolu
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-05 Thread FelixCui-oc
Hi  baolu,
>Sure. Before that, let me sync my understanding with you. You 
have an acpi namespace device in ANDD table, it also shows up in the device 
scope of a RMRR. 
>Current code doesn't enumerate that device for the RMRR, hence 
iommu_create_device_direct_mappings() doesn't work for this device.

>At the same time, probe_acpi_namespace_devices() doesn't work 
for this device, hence you want to add a home-made
>acpi_device_create_direct_mappings() helper.

Your understanding is right. 
But there is a problem that even if the namespace device in 
rmrr is enumerated in the code, probe_acpi_namespace_devices() also doesn't 
work for this device.
This is because the dev parameter of the 
iommu_create_device_direct_mappings() is not the namespace device in RMRR.
The actual parameter passed in is the namespace device's 
physical node device.
In iommu_create_device_direct_mappings(), the physical node 
device passed in cannot match the namespace device in rmrr->device[],right?
We need acpi_device_create_direct_mappings() helper ? 

In addition, adev->physical_node_list is related to the __HID 
of namespace device reported by the bios.
For example, if the __HID reported by the bios belongs to 
acpi_pnp_device_ids[], adev->physical_node_list has no devices.
So in acpi_device_create_direct_mappings(), I added the case 
that adev->physical_node_list is empty.


Best regards
Felix cui


 

-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月6日 10:36
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in 
RMRR

Hi Felix,

On 8/5/20 3:37 PM, FelixCui-oc wrote:
> Hi baolu,
>   Let me talk about why acpi_device_create_direct_mappings() is 
> needed and please tell me if there is an error.

Sure. Before that, let me sync my understanding with you. You have an acpi 
namespace device in ANDD table, it also shows up in the device scope of a RMRR. 
Current code doesn't enumerate that device for the RMRR, hence 
iommu_create_device_direct_mappings() doesn't work for this device.

At the same time, probe_acpi_namespace_devices() doesn't work for this device, 
hence you want to add a home-made
acpi_device_create_direct_mappings() helper.

Did I get it right?

>   In the probe_acpi_namespace_devices() function, only the device 
> in the addev->physical_node_list is probed,
>   but we need to establish identity mapping for the namespace 
> device in RMRR. These are two different devices.

The namespace device has been probed and put in one drhd's device list.
Hence, it should be processed by probe_acpi_namespace_devices(). So the 
question is why there are no devices in addev->physical_node_list?

>   Therefore, the namespace device in RMRR is not mapped in 
> probe_acpi_namespace_devices().
>   acpi_device_create_direct_mappings() is to create direct 
> mappings for namespace devices in RMRR.

Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-05 Thread FelixCui-oc
Hi baolu,
Let me talk about why acpi_device_create_direct_mappings() is 
needed and please tell me if there is an error.

In the probe_acpi_namespace_devices() function, only the device 
in the addev->physical_node_list is probed,
but we need to establish identity mapping for the namespace 
device in RMRR. These are two different devices.
Therefore, the namespace device in RMRR is not mapped in 
probe_acpi_namespace_devices(). 
acpi_device_create_direct_mappings() is to create direct 
mappings for namespace devices in RMRR.

Best regards
Felix cui-oc




-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月5日 10:57
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

Hi,

On 8/4/20 11:11 AM, FelixCui-oc wrote:
> Hi  baolu ,
>   When creating a identity mapping for a namespace device in 
> RMRR, you need to add the namespace device to the rmrr->device[] , right?

Yes. You are right.

>   The dmar_acpi_bus_add_dev() in patch adds the enumeration of 
> the 
> namespace device in RMRR. This is similar to > enumerating pci 
> devices. Do you think this is unreasonable? If it is
unreasonable, please tell me why it is unreasonable.

It looks reasonable. Thanks for the explanation.

But I don't think we need to add acpi_device_create_direct_mappings()
since the rmrr identity mapping is already done in the iommu core.

Best regards,
baolu

>   
> Best regards
> Felix cui-oc
> 
> 
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月4日 9:12
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in 
> RMRR
> 
> Hi Felix,
> 
> On 2020/8/3 17:41, FelixCui-oc wrote:
>> Hi baolu,
>>   dmar_acpi_dev_scope_init() parse ANDD structure and enumerated 
>> namespaces device in DRHD.
> 
> Yes.
> 
>>   But the namespace device in RMRR is not enumerated, right?
> 
> It should be probed in probe_acpi_namespace_devices().
> 
> Best regards,
> baolu
> 
>>
>> Best regards
>> Felix cui-oc
>>
>>
>>
>>
>> -邮件原件-
>> 发件人: FelixCui-oc
>> 发送时间: 2020年8月3日 17:02
>> 收件人: 'Lu Baolu' ; Joerg Roedel 
>> ; iommu@lists.linux-foundation.org; 
>> linux-ker...@vger.kernel.org; David Woodhouse 
>> 抄送: RaymondPang-oc ; CobeChen-oc 
>> 
>> 主题: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in 
>> RMRR
>>
>> Hi  baolu:
>>  "The namespace devices are enumerated in 
>> probe_acpi_namespace_devices().
>>  It calls iommu_probe_device() to process the enumeration and 
>> setup the identity mappings."
>>  
>>  This situation only applies to the physical node of the 
>> namespaces device as the pci device.
>>  In fact, the physical node of the namespaces device can be a 
>> platform device or NULL.
>>  If the physical node of the namespaces is a platform device or 
>> NULL, it has not actually been enumerated.
>>  So it is necessary to increase the analysis of the namespaces 
>> device in RMRR and establish an identity mapping.
>>
>> Best regards
>> Felix cui
>>
>>
>>
>>
>> -邮件原件-
>> 发件人: Lu Baolu 
>> 发送时间: 2020年8月3日 16:26
>> 收件人: FelixCui-oc ; Joerg Roedel 
>> ; iommu@lists.linux-foundation.org; 
>> linux-ker...@vger.kernel.org; David Woodhouse 
>> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
>> ; CobeChen-oc 
>> 主题: Re: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in 
>> RMRR
>>
>> On 2020/8/3 14:52, FelixCui-oc wrote:
>>> Hi  baolu ,
>>> Yes ,that's right.
>>> This patch is to achieve acpi namespace devices to access the 
>>> RMRR region.
>>
>> The namespace devices are enumerated in probe_acpi_namespace_devices().
>> It calls iommu_probe_device() to process the enumeration and setup the 
>> identity mappings. Can you please check why that code doesn't work for you?
>>
>> Best regards,
>> baolu
>>
>>>
>>> Best regards
>>> Felix cui
>>>
>>>
>>>
>>>
>>> --

答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-03 Thread FelixCui-oc
Hi  baolu ,
When creating a identity mapping for a namespace device in 
RMRR, you need to add the namespace device to the rmrr->device[] , right?
The dmar_acpi_bus_add_dev() in patch adds the enumeration of 
the namespace device in RMRR. This is similar to 
enumerating pci devices. Do you think this is unreasonable? If it is 
unreasonable, please tell me why it is unreasonable.

Best regards
Felix cui-oc



-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月4日 9:12
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

Hi Felix,

On 2020/8/3 17:41, FelixCui-oc wrote:
> Hi baolu,
>dmar_acpi_dev_scope_init() parse ANDD structure and enumerated 
> namespaces device in DRHD.

Yes.

>But the namespace device in RMRR is not enumerated, right?

It should be probed in probe_acpi_namespace_devices().

Best regards,
baolu

> 
> Best regards
> Felix cui-oc
> 
> 
> 
> 
> -邮件原件-
> 发件人: FelixCui-oc
> 发送时间: 2020年8月3日 17:02
> 收件人: 'Lu Baolu' ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: RaymondPang-oc ; CobeChen-oc 
> 
> 主题: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
> 
> Hi  baolu:
>   "The namespace devices are enumerated in 
> probe_acpi_namespace_devices().
>   It calls iommu_probe_device() to process the enumeration and 
> setup the identity mappings."
>   
>   This situation only applies to the physical node of the 
> namespaces device as the pci device.
>   In fact, the physical node of the namespaces device can be a 
> platform device or NULL.
>   If the physical node of the namespaces is a platform device or 
> NULL, it has not actually been enumerated.
>   So it is necessary to increase the analysis of the namespaces 
> device in RMRR and establish an identity mapping.
> 
> Best regards
> Felix cui
> 
> 
> 
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月3日 16:26
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
> 
> On 2020/8/3 14:52, FelixCui-oc wrote:
>> Hi  baolu ,
>>  Yes ,that's right.
>>  This patch is to achieve acpi namespace devices to access the 
>> RMRR region.
> 
> The namespace devices are enumerated in probe_acpi_namespace_devices().
> It calls iommu_probe_device() to process the enumeration and setup the 
> identity mappings. Can you please check why that code doesn't work for you?
> 
> Best regards,
> baolu
> 
>>
>> Best regards
>> Felix cui
>>
>>
>>
>>
>> -邮件原件-
>> 发件人: Lu Baolu 
>> 发送时间: 2020年8月3日 14:19
>> 收件人: FelixCui-oc ; Joerg Roedel 
>> ; iommu@lists.linux-foundation.org; 
>> linux-ker...@vger.kernel.org; David Woodhouse 
>> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
>> ; CobeChen-oc 
>> 主题: Re: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
>>
>> Hi,
>>
>> On 2020/8/3 12:40, FelixCui-oc wrote:
>>> Hi baolu:
>>> Some ACPI devices need to issue dma requests to access the 
>>> reserved memory area.
>>> So bios uses the device scope type ACPI_NAMESPACE_DEVICE in 
>>> RMRR to report these ACPI devices.
>>> At present, there is no analysis in the kernel that the device 
>>> scope type in RMRR is ACPI_NAMESPACE_DEVICE.
>>> This patch is mainly to add the analysis of the device scope 
>>> type ACPI_NAMESPACE_DEVICE in RMRR structure and establish identity mapping 
>>> for > these ACPI devices.
>>
>> So the problem is "although namespace devices in RMRR have been parsed, but 
>> the identity map for those devices aren't created. As the result, the 
>> namespace devices fail to access the RMRR region."
>>
>> Do I understand it right?
>>
>> Best regards,
>> baolu
>>
>>> In addition, some naming changes have been made in patch in order to 
>>> distinguish acpi device from pci device.
>>> You can refer to the description of type in 8.3.1 device scope 
>>> in vt-d spec.
>

答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-03 Thread FelixCui-oc
Hi baolu,
 dmar_acpi_dev_scope_init() parse ANDD structure and enumerated 
namespaces device in DRHD.
 But the namespace device in RMRR is not enumerated, right?

Best regards
Felix cui-oc




-邮件原件-
发件人: FelixCui-oc 
发送时间: 2020年8月3日 17:02
收件人: 'Lu Baolu' ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: RaymondPang-oc ; CobeChen-oc 

主题: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

Hi  baolu:
"The namespace devices are enumerated in 
probe_acpi_namespace_devices().
It calls iommu_probe_device() to process the enumeration and 
setup the identity mappings."

This situation only applies to the physical node of the 
namespaces device as the pci device.
In fact, the physical node of the namespaces device can be a 
platform device or NULL.
If the physical node of the namespaces is a platform device or 
NULL, it has not actually been enumerated.
So it is necessary to increase the analysis of the namespaces 
device in RMRR and establish an identity mapping.

Best regards
Felix cui




-邮件原件-
发件人: Lu Baolu 
发送时间: 2020年8月3日 16:26
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

On 2020/8/3 14:52, FelixCui-oc wrote:
> Hi  baolu ,
>   Yes ,that's right.
>   This patch is to achieve acpi namespace devices to access the 
> RMRR region.

The namespace devices are enumerated in probe_acpi_namespace_devices().
It calls iommu_probe_device() to process the enumeration and setup the identity 
mappings. Can you please check why that code doesn't work for you?

Best regards,
baolu

> 
> Best regards
> Felix cui
> 
> 
> 
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月3日 14:19
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
> 
> Hi,
> 
> On 2020/8/3 12:40, FelixCui-oc wrote:
>> Hi baolu:
>>  Some ACPI devices need to issue dma requests to access the 
>> reserved memory area.
>>  So bios uses the device scope type ACPI_NAMESPACE_DEVICE in 
>> RMRR to report these ACPI devices.
>>  At present, there is no analysis in the kernel that the device 
>> scope type in RMRR is ACPI_NAMESPACE_DEVICE.
>>  This patch is mainly to add the analysis of the device scope 
>> type ACPI_NAMESPACE_DEVICE in RMRR structure and establish identity mapping 
>> for > these ACPI devices.
> 
> So the problem is "although namespace devices in RMRR have been parsed, but 
> the identity map for those devices aren't created. As the result, the 
> namespace devices fail to access the RMRR region."
> 
> Do I understand it right?
> 
> Best regards,
> baolu
> 
>> In addition, some naming changes have been made in patch in order to 
>> distinguish acpi device from pci device.
>>  You can refer to the description of type in 8.3.1 device scope 
>> in vt-d spec.
>>
>> Best regards
>> FelixCui-oc
>>
>>
>>
>> -邮件原件-
>> 发件人: Lu Baolu 
>> 发送时间: 2020年8月3日 10:32
>> 收件人: FelixCui-oc ; Joerg Roedel 
>> ; iommu@lists.linux-foundation.org; 
>> linux-ker...@vger.kernel.org; David Woodhouse 
>> 抄送: baolu...@linux.intel.com; Cobe Chen(BJ-RD) 
>> ; Raymond Pang(BJ-RD) 
>> 主题: Re: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
>>
>> Hi,
>>
>> On 8/2/20 6:07 PM, FelixCuioc wrote:
>>> Some ACPI devices require access to the specified reserved memory 
>>> region.BIOS report the specified reserved memory region through RMRR 
>>> structures.Add analysis of ACPI device in RMRR and establish 
>>> identity mapping for ACPI device.
>>
>> Can you please add more words about the problem you want to solve? Do you 
>> mean some RMRRs are not enumerated correctly? Or, enumerated, but not 
>> identity mapped?
>>
>> Nit: add version and change log once you refreshed your patch.
>>
>>>
>>> Reported-by: kernel test robot 
>>
>> No need to add this. The problem you want to solve through this patch is not 
>> reported by lkp.
>>
>> Best regards,
>> baolu
>>
>>> Signed-off-b

答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-03 Thread FelixCui-oc
Hi  baolu:
"The namespace devices are enumerated in 
probe_acpi_namespace_devices().
It calls iommu_probe_device() to process the enumeration and 
setup the identity mappings."

This situation only applies to the physical node of the 
namespaces device as the pci device.
In fact, the physical node of the namespaces device can be a 
platform device or NULL.
If the physical node of the namespaces is a platform device or 
NULL, it has not actually been enumerated.
So it is necessary to increase the analysis of the namespaces 
device in RMRR and establish an identity mapping.

Best regards
Felix cui




-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月3日 16:26
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

On 2020/8/3 14:52, FelixCui-oc wrote:
> Hi  baolu ,
>   Yes ,that's right.
>   This patch is to achieve acpi namespace devices to access the 
> RMRR region.

The namespace devices are enumerated in probe_acpi_namespace_devices().
It calls iommu_probe_device() to process the enumeration and setup the identity 
mappings. Can you please check why that code doesn't work for you?

Best regards,
baolu

> 
> Best regards
> Felix cui
> 
> 
> 
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月3日 14:19
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
> 
> Hi,
> 
> On 2020/8/3 12:40, FelixCui-oc wrote:
>> Hi baolu:
>>  Some ACPI devices need to issue dma requests to access the 
>> reserved memory area.
>>  So bios uses the device scope type ACPI_NAMESPACE_DEVICE in 
>> RMRR to report these ACPI devices.
>>  At present, there is no analysis in the kernel that the device 
>> scope type in RMRR is ACPI_NAMESPACE_DEVICE.
>>  This patch is mainly to add the analysis of the device scope 
>> type ACPI_NAMESPACE_DEVICE in RMRR structure and establish identity mapping 
>> for > these ACPI devices.
> 
> So the problem is "although namespace devices in RMRR have been parsed, but 
> the identity map for those devices aren't created. As the result, the 
> namespace devices fail to access the RMRR region."
> 
> Do I understand it right?
> 
> Best regards,
> baolu
> 
>> In addition, some naming changes have been made in patch in order to 
>> distinguish acpi device from pci device.
>>  You can refer to the description of type in 8.3.1 device scope 
>> in vt-d spec.
>>
>> Best regards
>> FelixCui-oc
>>
>>
>>
>> -邮件原件-
>> 发件人: Lu Baolu 
>> 发送时间: 2020年8月3日 10:32
>> 收件人: FelixCui-oc ; Joerg Roedel 
>> ; iommu@lists.linux-foundation.org; 
>> linux-ker...@vger.kernel.org; David Woodhouse 
>> 抄送: baolu...@linux.intel.com; Cobe Chen(BJ-RD) 
>> ; Raymond Pang(BJ-RD) 
>> 主题: Re: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
>>
>> Hi,
>>
>> On 8/2/20 6:07 PM, FelixCuioc wrote:
>>> Some ACPI devices require access to the specified reserved memory 
>>> region.BIOS report the specified reserved memory region through RMRR 
>>> structures.Add analysis of ACPI device in RMRR and establish 
>>> identity mapping for ACPI device.
>>
>> Can you please add more words about the problem you want to solve? Do you 
>> mean some RMRRs are not enumerated correctly? Or, enumerated, but not 
>> identity mapped?
>>
>> Nit: add version and change log once you refreshed your patch.
>>
>>>
>>> Reported-by: kernel test robot 
>>
>> No need to add this. The problem you want to solve through this patch is not 
>> reported by lkp.
>>
>> Best regards,
>> baolu
>>
>>> Signed-off-by: FelixCuioc 
>>> ---
>>> drivers/iommu/intel/dmar.c  | 74 -
>>> drivers/iommu/intel/iommu.c | 46 ++-
>>> drivers/iommu/iommu.c   |  6 +++
>>> include/linux/dmar.h| 12 +-
>>> include/linux/iommu.h   |  3 ++
>>> 5 files changed, 105 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/iommu/intel/dmar.c 

答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-02 Thread FelixCui-oc
Hi  baolu ,
Yes ,that's right.
This patch is to achieve acpi namespace devices to access the 
RMRR region.

Best regards
Felix cui




-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月3日 14:19
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

Hi,

On 2020/8/3 12:40, FelixCui-oc wrote:
> Hi baolu:
>   Some ACPI devices need to issue dma requests to access the 
> reserved memory area.
>   So bios uses the device scope type ACPI_NAMESPACE_DEVICE in 
> RMRR to report these ACPI devices.
>   At present, there is no analysis in the kernel that the device 
> scope type in RMRR is ACPI_NAMESPACE_DEVICE.
>   This patch is mainly to add the analysis of the device scope 
> type ACPI_NAMESPACE_DEVICE in RMRR structure and establish identity mapping 
> for > these ACPI devices.

So the problem is "although namespace devices in RMRR have been parsed, but the 
identity map for those devices aren't created. As the result, the namespace 
devices fail to access the RMRR region."

Do I understand it right?

Best regards,
baolu

> In addition, some naming changes have been made in patch in order to 
> distinguish acpi device from pci device.
>   You can refer to the description of type in 8.3.1 device scope 
> in vt-d spec.
> 
> Best regards
> FelixCui-oc
> 
> 
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月3日 10:32
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; iommu@lists.linux-foundation.org; 
> linux-ker...@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; Cobe Chen(BJ-RD) ; 
> Raymond Pang(BJ-RD) 
> 主题: Re: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
> 
> Hi,
> 
> On 8/2/20 6:07 PM, FelixCuioc wrote:
>> Some ACPI devices require access to the specified reserved memory 
>> region.BIOS report the specified reserved memory region through RMRR 
>> structures.Add analysis of ACPI device in RMRR and establish identity 
>> mapping for ACPI device.
> 
> Can you please add more words about the problem you want to solve? Do you 
> mean some RMRRs are not enumerated correctly? Or, enumerated, but not 
> identity mapped?
> 
> Nit: add version and change log once you refreshed your patch.
> 
>>
>> Reported-by: kernel test robot 
> 
> No need to add this. The problem you want to solve through this patch is not 
> reported by lkp.
> 
> Best regards,
> baolu
> 
>> Signed-off-by: FelixCuioc 
>> ---
>>drivers/iommu/intel/dmar.c  | 74 -
>>drivers/iommu/intel/iommu.c | 46 ++-
>>drivers/iommu/iommu.c   |  6 +++
>>include/linux/dmar.h| 12 +-
>>include/linux/iommu.h   |  3 ++
>>5 files changed, 105 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c 
>> index 93e6345f3414..024ca38dba12 100644
>> --- a/drivers/iommu/intel/dmar.c
>> +++ b/drivers/iommu/intel/dmar.c
>> @@ -215,7 +215,7 @@ static bool dmar_match_pci_path(struct 
>> dmar_pci_notify_info *info, int bus,
>>}
>>
>>/* Return: > 0 if match found, 0 if no match found, < 0 if error 
>> happens */ -int dmar_insert_dev_scope(struct dmar_pci_notify_info 
>> *info,
>> +int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info,
>>void *start, void*end, u16 segment,
>>struct dmar_dev_scope *devices,
>>int devices_cnt)
>> @@ -304,7 +304,7 @@ static int dmar_pci_bus_add_dev(struct 
>> dmar_pci_notify_info *info)
>>
>>  drhd = container_of(dmaru->hdr,
>>  struct acpi_dmar_hardware_unit, header);
>> -ret = dmar_insert_dev_scope(info, (void *)(drhd + 1),
>> +ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1),
>>  ((void *)drhd) + drhd->header.length,
>>  dmaru->segment,
>>  dmaru->devices, dmaru->devices_cnt); @@ -696,48 
>> +696,56 @@ 
>> dmar_find_matched_drhd_unit(struct pci_dev *dev)
>>
>>  return dmaru;
>>}
>> -
>> -static void __init dmar_acpi_insert_dev_scope(u8 device_number,
>> -  struct acpi_device *adev)
>> +int dmar_acpi_insert_dev_scope(u8 device_number,
>> +

答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

2020-08-02 Thread FelixCui-oc
Hi baolu:
Some ACPI devices need to issue dma requests to access the 
reserved memory area.
So bios uses the device scope type ACPI_NAMESPACE_DEVICE in 
RMRR to report these ACPI devices.
At present, there is no analysis in the kernel that the device 
scope type in RMRR is ACPI_NAMESPACE_DEVICE.
This patch is mainly to add the analysis of the device scope 
type ACPI_NAMESPACE_DEVICE in RMRR structure and establish identity mapping for 
these ACPI devices. In addition, some naming changes have been made in patch in 
order to distinguish acpi device from pci device.
You can refer to the description of type in 8.3.1 device scope 
in vt-d spec.

Best regards
FelixCui-oc



-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月3日 10:32
收件人: FelixCui-oc ; Joerg Roedel ; 
iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; Cobe Chen(BJ-RD) ; Raymond 
Pang(BJ-RD) 
主题: Re: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

Hi,

On 8/2/20 6:07 PM, FelixCuioc wrote:
> Some ACPI devices require access to the specified reserved memory 
> region.BIOS report the specified reserved memory region through RMRR 
> structures.Add analysis of ACPI device in RMRR and establish identity 
> mapping for ACPI device.

Can you please add more words about the problem you want to solve? Do you mean 
some RMRRs are not enumerated correctly? Or, enumerated, but not identity 
mapped?

Nit: add version and change log once you refreshed your patch.

> 
> Reported-by: kernel test robot 

No need to add this. The problem you want to solve through this patch is not 
reported by lkp.

Best regards,
baolu

> Signed-off-by: FelixCuioc 
> ---
>   drivers/iommu/intel/dmar.c  | 74 -
>   drivers/iommu/intel/iommu.c | 46 ++-
>   drivers/iommu/iommu.c   |  6 +++
>   include/linux/dmar.h| 12 +-
>   include/linux/iommu.h   |  3 ++
>   5 files changed, 105 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c 
> index 93e6345f3414..024ca38dba12 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -215,7 +215,7 @@ static bool dmar_match_pci_path(struct 
> dmar_pci_notify_info *info, int bus,
>   }
>   
>   /* Return: > 0 if match found, 0 if no match found, < 0 if error 
> happens */ -int dmar_insert_dev_scope(struct dmar_pci_notify_info 
> *info,
> +int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info,
> void *start, void*end, u16 segment,
> struct dmar_dev_scope *devices,
> int devices_cnt)
> @@ -304,7 +304,7 @@ static int dmar_pci_bus_add_dev(struct 
> dmar_pci_notify_info *info)
>   
>   drhd = container_of(dmaru->hdr,
>   struct acpi_dmar_hardware_unit, header);
> - ret = dmar_insert_dev_scope(info, (void *)(drhd + 1),
> + ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1),
>   ((void *)drhd) + drhd->header.length,
>   dmaru->segment,
>   dmaru->devices, dmaru->devices_cnt); @@ -696,48 
> +696,56 @@ 
> dmar_find_matched_drhd_unit(struct pci_dev *dev)
>   
>   return dmaru;
>   }
> -
> -static void __init dmar_acpi_insert_dev_scope(u8 device_number,
> -   struct acpi_device *adev)
> +int dmar_acpi_insert_dev_scope(u8 device_number,
> + struct acpi_device *adev,
> + void *start, void *end,
> + struct dmar_dev_scope *devices,
> + int devices_cnt)
>   {
> - struct dmar_drhd_unit *dmaru;
> - struct acpi_dmar_hardware_unit *drhd;
>   struct acpi_dmar_device_scope *scope;
>   struct device *tmp;
>   int i;
>   struct acpi_dmar_pci_path *path;
>   
> + for (; start < end; start += scope->length) {
> + scope = start;
> + if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
> + continue;
> + if (scope->enumeration_id != device_number)
> + continue;
> + path = (void *)(scope + 1);
> + for_each_dev_scope(devices, devices_cnt, i, tmp)
> + if (tmp == NULL) {
> + devices[i].bus = scope->bus;
> + devices[i].devfn = PCI_DEVFN(path->device, 
> path->function);
> + rcu_assign_pointer(devices[i]