Re: [PATCH v2 13/17] x86/setup: simplify initrd relocation and reservation
On Wed, Aug 05, 2020 at 12:20:24PM +0800, Baoquan He wrote: > On 08/02/20 at 07:35pm, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Currently, initrd image is reserved very early during setup and then it > > might be relocated and re-reserved after the initial physical memory > > mapping is created. The "late" reservation of memblock verifies that mapped > > memory size exceeds the size of initrd, the checks whether the relocation > ~ then? Right, thanks! > > required and, if yes, relocates inirtd to a new memory allocated from > > memblock and frees the old location. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 13/17] x86/setup: simplify initrd relocation and reservation
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Currently, initrd image is reserved very early during setup and then it
> might be relocated and re-reserved after the initial physical memory
> mapping is created. The "late" reservation of memblock verifies that mapped
> memory size exceeds the size of initrd, the checks whether the relocation
~ then?
> required and, if yes, relocates inirtd to a new memory allocated from
> memblock and frees the old location.
>
> The check for memory size is excessive as memblock allocation will anyway
> fail if there is not enough memory. Besides, there is no point to allocate
> memory from memblock using memblock_find_in_range() + memblock_reserve()
> when there exists memblock_phys_alloc_range() with required functionality.
>
> Remove the redundant check and simplify memblock allocation.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/x86/kernel/setup.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index a3767e74c758..d8de4053c5e8 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -262,16 +262,12 @@ static void __init relocate_initrd(void)
> u64 area_size = PAGE_ALIGN(ramdisk_size);
>
> /* We need to move the initrd down into directly mapped mem */
> - relocated_ramdisk = memblock_find_in_range(0, PFN_PHYS(max_pfn_mapped),
> -area_size, PAGE_SIZE);
> -
> + relocated_ramdisk = memblock_phys_alloc_range(area_size, PAGE_SIZE, 0,
> + PFN_PHYS(max_pfn_mapped));
> if (!relocated_ramdisk)
> panic("Cannot find place for new RAMDISK of size %lld\n",
> ramdisk_size);
>
> - /* Note: this includes all the mem currently occupied by
> -the initrd, we rely on that fact to keep the data intact. */
> - memblock_reserve(relocated_ramdisk, area_size);
> initrd_start = relocated_ramdisk + PAGE_OFFSET;
> initrd_end = initrd_start + ramdisk_size;
> printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n",
> @@ -298,13 +294,13 @@ static void __init early_reserve_initrd(void)
>
> memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
> }
> +
> static void __init reserve_initrd(void)
> {
> /* Assume only end is not page aligned */
> u64 ramdisk_image = get_ramdisk_image();
> u64 ramdisk_size = get_ramdisk_size();
> u64 ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> - u64 mapped_size;
>
> if (!boot_params.hdr.type_of_loader ||
> !ramdisk_image || !ramdisk_size)
> @@ -312,12 +308,6 @@ static void __init reserve_initrd(void)
>
> initrd_start = 0;
>
> - mapped_size = memblock_mem_size(max_pfn_mapped);
> - if (ramdisk_size >= (mapped_size>>1))
> - panic("initrd too large to handle, "
> -"disabling initrd (%lld needed, %lld available)\n",
> -ramdisk_size, mapped_size>>1);
Reviewed-by: Baoquan He
> -
> printk(KERN_INFO "RAMDISK: [mem %#010llx-%#010llx]\n", ramdisk_image,
> ramdisk_end - 1);
>
> --
> 2.26.2
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 11/17] arch, mm: replace for_each_memblock() with for_each_mem_pfn_range()
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start_pfn = memblock_region_memory_base_pfn(reg);
> end_pfn = memblock_region_memory_end_pfn(reg);
>
> /* do something with start_pfn and end_pfn */
> }
>
> Rather than iterate over all memblock.memory regions and each time query
> for their start and end PFNs, use for_each_mem_pfn_range() iterator to get
> simpler and clearer code.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/arm/mm/init.c | 11 ---
> arch/arm64/mm/init.c | 11 ---
> arch/powerpc/kernel/fadump.c | 11 ++-
> arch/powerpc/mm/mem.c| 15 ---
> arch/powerpc/mm/numa.c | 7 ++-
> arch/s390/mm/page-states.c | 6 ++
> arch/sh/mm/init.c| 9 +++--
> mm/memblock.c| 6 ++
> mm/sparse.c | 10 --
> 9 files changed, 35 insertions(+), 51 deletions(-)
>
Reviewed-by: Baoquan He
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 02/17] dma-contiguous: simplify cma_early_percent_memory()
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The memory size calculation in cma_early_percent_memory() traverses
> memblock.memory rather than simply call memblock_phys_mem_size(). The
> comment in that function suggests that at some point there should have been
> call to memblock_analyze() before memblock_phys_mem_size() could be used.
> As of now, there is no memblock_analyze() at all and
> memblock_phys_mem_size() can be used as soon as cold-plug memory is
> registerd with memblock.
>
> Replace loop over memblock.memory with a call to memblock_phys_mem_size().
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: Christoph Hellwig
> ---
> kernel/dma/contiguous.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 15bc5026c485..1992afd8ca7b 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -73,16 +73,7 @@ early_param("cma", early_cma);
>
> static phys_addr_t __init __maybe_unused cma_early_percent_memory(void)
> {
> - struct memblock_region *reg;
> - unsigned long total_pages = 0;
> -
> - /*
> - * We cannot use memblock_phys_mem_size() here, because
> - * memblock_analyze() has not been called yet.
> - */
> - for_each_memblock(memory, reg)
> - total_pages += memblock_region_memory_end_pfn(reg) -
> -memblock_region_memory_base_pfn(reg);
> + unsigned long total_pages = PHYS_PFN(memblock_phys_mem_size());
Reviewed-by: Baoquan He
>
> return (total_pages * CONFIG_CMA_SIZE_PERCENTAGE / 100) << PAGE_SHIFT;
> }
> --
> 2.26.2
>
___
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, 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 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
Re: [GIT PULL] dma-mapping updates for 5.9
The pull request you sent on Mon, 3 Aug 2020 16:15:47 +0200: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.9 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2ed90dbbf7be3b7cd2790fc6fa946c478ab496b8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 01/17] KVM: PPC: Book3S HV: simplify kvm_cma_reserve()
Hi Mike,
>
> The memory size calculation in kvm_cma_reserve() traverses memblock.memory
> rather than simply call memblock_phys_mem_size(). The comment in that
> function suggests that at some point there should have been call to
> memblock_analyze() before memblock_phys_mem_size() could be used.
> As of now, there is no memblock_analyze() at all and
> memblock_phys_mem_size() can be used as soon as cold-plug memory is
> registerd with memblock.
>
> Replace loop over memblock.memory with a call to memblock_phys_mem_size().
>
> Signed-off-by: Mike Rapoport
> ---
> arch/powerpc/kvm/book3s_hv_builtin.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
> b/arch/powerpc/kvm/book3s_hv_builtin.c
> index 7cd3cf3d366b..56ab0d28de2a 100644
> --- a/arch/powerpc/kvm/book3s_hv_builtin.c
> +++ b/arch/powerpc/kvm/book3s_hv_builtin.c
> @@ -95,22 +95,15 @@ EXPORT_SYMBOL_GPL(kvm_free_hpt_cma);
> void __init kvm_cma_reserve(void)
> {
> unsigned long align_size;
> - struct memblock_region *reg;
> - phys_addr_t selected_size = 0;
> + phys_addr_t selected_size;
>
> /*
>* We need CMA reservation only when we are in HV mode
>*/
> if (!cpu_has_feature(CPU_FTR_HVMODE))
> return;
> - /*
> - * We cannot use memblock_phys_mem_size() here, because
> - * memblock_analyze() has not been called yet.
> - */
> - for_each_memblock(memory, reg)
> - selected_size += memblock_region_memory_end_pfn(reg) -
> - memblock_region_memory_base_pfn(reg);
>
> + selected_size = PHYS_PFN(memblock_phys_mem_size());
> selected_size = (selected_size * kvm_cma_resv_ratio / 100) <<
> PAGE_SHIFT;
I think this is correct, but PHYS_PFN does x >> PAGE_SHIFT and then the
next line does x << PAGE_SHIFT, so I think we could combine those two
lines as:
selected_size = PAGE_ALIGN(memblock_phys_mem_size() * kvm_cma_resv_ratio / 100);
(I think that might technically change it from aligning down to aligning
up but I don't think 1 page matters here.)
Kind regards,
Daniel
> if (selected_size) {
> pr_debug("%s: reserving %ld MiB for global area\n", __func__,
> --
> 2.26.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
VFIO/IOMMU/PCI MC at LPC20 - Call for Topics
Hi all, following up the LPC20 blog announcement: https://www.linuxplumbersconf.org/blog/2020/vfio-iommu-pci-microconference-accepted-into-2020-linux-plumbers-conference/ The call for topics for the VFIO/IOMMU/PCI microconference at LPC20 is now open, the LPC20 entry below provides a list of possible topics but you should feel free to submit topics of interest that you would like to discuss with maintainers and developers of the respective subsystems. https://www.linuxplumbersconf.org/event/7/page/80-accepted-microconferences#vfio-cr Please do reach out for any other piece of information we can help with. Looking forward to receiving your submissions ! Thanks, Lorenzo ___ 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, 2020-08-04 at 08:06 +0200, Christoph Hellwig wrote: > On Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote: > > + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA)) > > + return end <= DMA_BIT_MASK(zone_dma_bits); > > + if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32)) > > + return end <= DMA_BIT_MASK(32); > > + if (gfp & GFP_KERNEL) > > + return end > DMA_BIT_MASK(32); > > So the GFP_KERNEL one here looks weird. For one I don't think the if > line is needed at all, and it just confuses things. Yes, sorry, shoud've seen that. > 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. Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ 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 Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote: > + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA)) > + return end <= DMA_BIT_MASK(zone_dma_bits); > + if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32)) > + return end <= DMA_BIT_MASK(32); > + if (gfp & GFP_KERNEL) > + return end > DMA_BIT_MASK(32); So the GFP_KERNEL one here looks weird. For one I don't think the if line is needed at all, and it just confuses things. 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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
