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
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 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
[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,
->pgsize_bitmap);
+ virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
+ >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,
-_start);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
+ struct virtio_iommu_config, input_range.start,
+ _start);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
-struct virtio_iommu_config, input_range.end,
-_end);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
+ struct virtio_iommu_config, input_range.end,
+ _end);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
-struct virtio_iommu_config, domain_range.start,
->first_domain);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
+ struct virtio_iommu_config, domain_range.start,
+ >first_domain);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
-struct virtio_iommu_config, domain_range.end,
->last_domain);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_RANGE,
+ struct virtio_iommu_config, domain_range.end,
+ >last_domain);
- virtio_cread_feature(vdev, VIRTIO_IOMMU_F_PROBE,
-struct virtio_iommu_config, probe_size,
->probe_size);
+ virtio_cread_le_feature(vdev, VIRTIO_IOMMU_F_PROBE,
+ struct virtio_iommu_config, probe_size,
+ >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 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
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 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 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 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, _pfn, _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
答复: 答复: 答复: 答复: 答复: [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 14/17] x86/setup: simplify reserve_crashkernel()
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> * Replace magic numbers with defines
> * Replace memblock_find_in_range() + memblock_reserve() with
> memblock_phys_alloc_range()
> * Stop checking for low memory size in reserve_crashkernel_low(). The
> allocation from limited range will anyway fail if there is no enough
> memory, so there is no need for extra traversal of memblock.memory
>
> Signed-off-by: Mike Rapoport
> ---
> arch/x86/kernel/setup.c | 40 ++--
> 1 file changed, 14 insertions(+), 26 deletions(-)
Applied this patch on top of 5.8, crashkernel reservation works well.
And the code change looks good.
Reviewed-by: Baoquan He
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d8de4053c5e8..d7ced6982524 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -419,13 +419,13 @@ static int __init reserve_crashkernel_low(void)
> {
> #ifdef CONFIG_X86_64
> unsigned long long base, low_base = 0, low_size = 0;
> - unsigned long total_low_mem;
> + unsigned long low_mem_limit;
> int ret;
>
> - total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
> + low_mem_limit = min(memblock_phys_mem_size(), CRASH_ADDR_LOW_MAX);
>
> /* crashkernel=Y,low */
> - ret = parse_crashkernel_low(boot_command_line, total_low_mem,
> _size, );
> + ret = parse_crashkernel_low(boot_command_line, low_mem_limit,
> _size, );
> if (ret) {
> /*
>* two parts from kernel/dma/swiotlb.c:
> @@ -443,23 +443,17 @@ static int __init reserve_crashkernel_low(void)
> return 0;
> }
>
> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
> CRASH_ADDR_LOW_MAX);
> if (!low_base) {
> pr_err("Cannot reserve %ldMB crashkernel low memory, please try
> smaller size.\n",
> (unsigned long)(low_size >> 20));
> return -ENOMEM;
> }
>
> - ret = memblock_reserve(low_base, low_size);
> - if (ret) {
> - pr_err("%s: Error reserving crashkernel low memblock.\n",
> __func__);
> - return ret;
> - }
> -
> - pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System
> low RAM: %ldMB)\n",
> + pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (low
> RAM limit: %ldMB)\n",
> (unsigned long)(low_size >> 20),
> (unsigned long)(low_base >> 20),
> - (unsigned long)(total_low_mem >> 20));
> + (unsigned long)(low_mem_limit >> 20));
>
> crashk_low_res.start = low_base;
> crashk_low_res.end = low_base + low_size - 1;
> @@ -503,13 +497,13 @@ static void __init reserve_crashkernel(void)
>* unless "crashkernel=size[KMG],high" is specified.
>*/
> if (!high)
> - crash_base = memblock_find_in_range(CRASH_ALIGN,
> - CRASH_ADDR_LOW_MAX,
> - crash_size, CRASH_ALIGN);
> + crash_base = memblock_phys_alloc_range(crash_size,
> + CRASH_ALIGN, CRASH_ALIGN,
> + CRASH_ADDR_LOW_MAX);
> if (!crash_base)
> - crash_base = memblock_find_in_range(CRASH_ALIGN,
> - CRASH_ADDR_HIGH_MAX,
> - crash_size, CRASH_ALIGN);
> + crash_base = memblock_phys_alloc_range(crash_size,
> + CRASH_ALIGN, CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX);
> if (!crash_base) {
> pr_info("crashkernel reservation failed - No suitable
> area found.\n");
> return;
> @@ -517,19 +511,13 @@ static void __init reserve_crashkernel(void)
> } else {
> unsigned long long start;
>
> - start = memblock_find_in_range(crash_base,
> -crash_base + crash_size,
> -crash_size, 1 << 20);
> + start = memblock_phys_alloc_range(crash_size, SZ_1M, crash_base,
> + crash_base + crash_size);
> if (start != crash_base) {
> pr_info("crashkernel reservation failed - memory is in
> use.\n");
> return;
> }
> }
> - ret = memblock_reserve(crash_base, crash_size);
> - if (ret) {
> - pr_err("%s: Error reserving crashkernel memblock.\n", __func__);
> - return;
> - }
>
> if (crash_base >= (1ULL << 32)
