答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR
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 >>> >>> >>> >>> >>> -邮件原件- >>> 发件人: 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
Re: [PATCH v2 15/17] memblock: remove unused memblock_mem_size()
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The only user of memblock_mem_size() was x86 setup code, it is gone now and
> memblock_mem_size() funciton can be removed.
>
> Signed-off-by: Mike Rapoport
> ---
> include/linux/memblock.h | 1 -
> mm/memblock.c| 15 ---
> 2 files changed, 16 deletions(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index d70c2835e913..ec2fd8f32a19 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -450,7 +450,6 @@ static inline bool memblock_bottom_up(void)
>
> phys_addr_t memblock_phys_mem_size(void);
> phys_addr_t memblock_reserved_size(void);
> -phys_addr_t memblock_mem_size(unsigned long limit_pfn);
> phys_addr_t memblock_start_of_DRAM(void);
> phys_addr_t memblock_end_of_DRAM(void);
> void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> diff --git a/mm/memblock.c b/mm/memblock.c
> index c1a4c8798973..48d614352b25 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1656,21 +1656,6 @@ phys_addr_t __init_memblock
> memblock_reserved_size(void)
> return memblock.reserved.total_size;
> }
>
> -phys_addr_t __init memblock_mem_size(unsigned long limit_pfn)
> -{
> - unsigned long pages = 0;
> - unsigned long start_pfn, end_pfn;
> - int i;
> -
> - for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, NULL) {
> - start_pfn = min_t(unsigned long, start_pfn, limit_pfn);
> - end_pfn = min_t(unsigned long, end_pfn, limit_pfn);
> - pages += end_pfn - start_pfn;
> - }
> -
> - return PFN_PHYS(pages);
> -}
Reviewed-by: Baoquan He
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 16/17] memblock: implement for_each_reserved_mem_region() using __next_mem_region()
On 08/02/20 at 07:36pm, Mike Rapoport wrote: > From: Mike Rapoport > > Iteration over memblock.reserved with for_each_reserved_mem_region() used > __next_reserved_mem_region() that implemented a subset of > __next_mem_region(). > > Use __for_each_mem_range() and, essentially, __next_mem_region() with > appropriate parameters to reduce code duplication. > > While on it, rename for_each_reserved_mem_region() to > for_each_reserved_mem_range() for consistency. > > Signed-off-by: Mike Rapoport > --- > .clang-format| 2 +- > arch/arm64/kernel/setup.c| 2 +- > drivers/irqchip/irq-gic-v3-its.c | 2 +- > include/linux/memblock.h | 12 +++-- > mm/memblock.c| 46 +++- > 5 files changed, 17 insertions(+), 47 deletions(-) Reviewed-by: Baoquan He ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 17/17] memblock: use separate iterators for memory and reserved regions
On 08/02/20 at 07:36pm, Mike Rapoport wrote: > From: Mike Rapoport > > for_each_memblock() is used to iterate over memblock.memory in > a few places that use data from memblock_region rather than the memory > ranges. > > Introduce separate for_each_mem_region() and for_each_reserved_mem_region() > to improve encapsulation of memblock internals from its users. > > Signed-off-by: Mike Rapoport > --- > .clang-format | 3 ++- > arch/arm64/kernel/setup.c | 2 +- > arch/arm64/mm/numa.c | 2 +- > arch/mips/netlogic/xlp/setup.c | 2 +- > arch/x86/mm/numa.c | 2 +- > include/linux/memblock.h | 19 --- > mm/memblock.c | 4 ++-- > mm/page_alloc.c| 8 > 8 files changed, 28 insertions(+), 14 deletions(-) > ... > diff --git a/include/linux/memblock.h b/include/linux/memblock.h > index 9e51b3fd4134..a6970e058bd7 100644 > --- a/include/linux/memblock.h > +++ b/include/linux/memblock.h > @@ -522,9 +522,22 @@ static inline unsigned long > memblock_region_reserved_end_pfn(const struct memblo > return PFN_UP(reg->base + reg->size); > } > > -#define for_each_memblock(memblock_type, region) > \ > - for (region = memblock.memblock_type.regions; > \ > - region < (memblock.memblock_type.regions + > memblock.memblock_type.cnt);\ > +/** > + * for_each_mem_region - itereate over registered memory regions ~ Wonder why emphasize 'registered' memory. Other than this confusion to me, this patch looks good. Reviewed-by: Baoquan He ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 12/17] arch, drivers: replace for_each_membock() with for_each_mem_range()
On Sun, Aug 02, 2020 at 07:35:56PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
> end = __pfn_to_phys(memblock_region_memory_end_pfn(reg));
>
> /* do something with start and end */
> }
>
> Using for_each_mem_range() iterator is more appropriate in such cases and
> allows simpler and cleaner code.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/mips/cavium-octeon/dma-octeon.c | 12 +++---
> arch/mips/kernel/setup.c | 31 +++
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 17/17] memblock: use separate iterators for memory and reserved regions
On Sun, Aug 02, 2020 at 07:36:01PM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > for_each_memblock() is used to iterate over memblock.memory in > a few places that use data from memblock_region rather than the memory > ranges. > > Introduce separate for_each_mem_region() and for_each_reserved_mem_region() > to improve encapsulation of memblock internals from its users. > > Signed-off-by: Mike Rapoport > --- > arch/mips/netlogic/xlp/setup.c | 2 +- Acked-by: Thomas Bogendoerfer Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ] ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 36/38] virtio-iommu: convert to LE accessors
Virtio iommu is modern-only. Use LE accessors for config space.
Signed-off-by: Michael S. Tsirkin
---
drivers/iommu/virtio-iommu.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index f6f07489a9aa..b4da396cce60 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1010,8 +1010,8 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
return ret;
- virtio_cread(vdev, struct virtio_iommu_config, page_size_mask,
-&viommu->pgsize_bitmap);
+ virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
+ &viommu->pgsize_bitmap);
if (!viommu->pgsize_bitmap) {
ret = -EINVAL;
@@ -1022,25 +1022,25 @@ static int viommu_probe(struct virtio_device *vdev)
viommu->last_domain = ~0U;
/* Optional features */
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
-struct virtio_iommu_config, input_range.start,
-&input_start);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
+ struct virtio_iommu_config, input_range.start,
+ &input_start);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
-struct virtio_iommu_config, input_range.end,
-&input_end);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
+ struct virtio_iommu_config, input_range.end,
+ &input_end);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
-struct virtio_iommu_config, domain_range.start,
-&viommu->first_domain);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
+ struct virtio_iommu_config, domain_range.start,
+ &viommu->first_domain);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
-struct virtio_iommu_config, domain_range.end,
-&viommu->last_domain);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
+ struct virtio_iommu_config, domain_range.end,
+ &viommu->last_domain);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_PROBE,
-struct virtio_iommu_config, probe_size,
-&viommu->probe_size);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_PROBE,
+ struct virtio_iommu_config, probe_size,
+ &viommu->probe_size);
viommu->geometry = (struct iommu_domain_geometry) {
.aperture_start = input_start,
--
MST
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 17/17] memblock: use separate iterators for memory and reserved regions
On Sun, Aug 2, 2020 at 6:41 PM Mike Rapoport wrote: > > .clang-format | 3 ++- The .clang-format bit: Acked-by: Miguel Ojeda Cheers, Miguel ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 16/17] memblock: implement for_each_reserved_mem_region() using __next_mem_region()
On Sun, Aug 2, 2020 at 6:40 PM Mike Rapoport wrote: > > .clang-format| 2 +- The .clang-format bit: Acked-by: Miguel Ojeda Cheers, Miguel ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
Re: [PATCH v2 2/2] dma-pool: Only allocate from CMA when in same memory zone
On Tue, Aug 04, 2020 at 11:43:15AM +0200, Nicolas Saenz Julienne wrote: > > Second I don't see the need (and actually some harm) in preventing > > GFP_KERNEL > > allocations from dipping into lower CMA areas - something that we did > > support > > before 5.8 with the single pool. > > My thinking is the least we pressure CMA the better, it's generally scarse, > and > it'll not grow as the atomic pools grow. As far as harm is concerned, we now > check addresses for correctness, so we shouldn't run into problems. > > There is a potential case for architectures defining a default CMA but not > defining DMA zones where this could be problematic. But isn't that just plain > abusing CMA? If you need low memory allocations, you should be defining DMA > zones. The latter is pretty much what I expect, as we only support the default and per-device DMA CMAs. ___ 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
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
Re: [RFC PATCH] dma-iommu: allow devices to set IOVA range dynamically
I'm not entirely sure this is the right mechanism. Can you please send it along with your intended user so that we can get a better picture? Also the export needs to be a _GPL one for any kind of functionality like this, ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
