All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 8/8] xen/riscv: introduce early_fdt_map()
Date: Mon, 15 Jul 2024 10:52:21 +0200	[thread overview]
Message-ID: <bc8d2e10-0898-4f5a-b296-1bc7f528bb77@suse.com> (raw)
In-Reply-To: <4e4f94817fb3bba5f52336ea0b4491f7bc867d49.1720799926.git.oleksii.kurochko@gmail.com>

On 12.07.2024 18:22, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -266,4 +266,6 @@ static inline unsigned int arch_get_dma_bitsize(void)
>  
>  void setup_fixmap_mappings(void);
>  
> +void* early_fdt_map(paddr_t fdt_paddr);

Please can you take care to address comments on earlier versions before
submitting a new one?

> @@ -435,3 +438,55 @@ inline pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr)
>  
>      return mfn_to_pte(mfn);
>  }
> +
> +void * __init early_fdt_map(paddr_t fdt_paddr)
> +{
> +    /* We are using 2MB superpage for mapping the FDT */
> +    paddr_t base_paddr = fdt_paddr & XEN_PT_LEVEL_MAP_MASK(1);
> +    paddr_t offset;
> +    void *fdt_virt;
> +    uint32_t size;
> +    int rc;
> +
> +    /*
> +     * Check whether the physical FDT address is set and meets the minimum
> +     * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
> +     * least 8 bytes so that we always access the magic and size fields
> +     * of the FDT header after mapping the first chunk, double check if
> +     * that is indeed the case.
> +     */
> +    BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
> +    if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
> +        return NULL;
> +
> +    /* The FDT is mapped using 2MB superpage */
> +    BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);

May I suggest that you use MB(2) instead of SZ_2M (not just here)? I think
I had voiced opposition to the introduction of xen/sizes.h about 10 years
back, yet sadly it still landed in the tree. I for one think that our KB(),
MB(), and GB() constructs are superior, and (I hope) free of Misra issues
(unlike SZ_2G).

> +    rc = map_pages_to_xen(BOOT_FDT_VIRT_START, maddr_to_mfn(base_paddr),
> +                          SZ_2M >> PAGE_SHIFT,
> +                          PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
> +    if ( rc )
> +        panic("Unable to map the device-tree.\n");
> +
> +    offset = fdt_paddr % XEN_PT_LEVEL_SIZE(1);
> +    fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
> +
> +    if ( fdt_magic(fdt_virt) != FDT_MAGIC )
> +        return NULL;
> +
> +    size = fdt_totalsize(fdt_virt);
> +    if ( size > BOOT_FDT_VIRT_SIZE )
> +        return NULL;
> +
> +    if ( (offset + size) > SZ_2M )
> +    {
> +        rc = map_pages_to_xen(BOOT_FDT_VIRT_START + SZ_2M,
> +                              maddr_to_mfn(base_paddr + SZ_2M),
> +                              SZ_2M >> PAGE_SHIFT,
> +                              PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
> +        if ( rc )
> +            panic("Unable to map the device-tree\n");
> +    }

Why this two part mapping? And why are you mapping perhaps much more
than "size"?

> @@ -48,6 +49,14 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>  
>      setup_fixmap_mappings();
>  
> +    device_tree_flattened = early_fdt_map(dtb_addr);
> +    if ( device_tree_flattened )

Is this condition perhaps inverted?

Jan

> +        panic("Invalid device tree blob at physical address %#lx.\n"
> +              "The DTB must be 8-byte aligned and must not exceed %lld "
> +              "bytes in size.\n\n"
> +              "Please check your bootloader.\n",
> +              dtb_addr, BOOT_FDT_VIRT_SIZE);
> +
>      printk("All set up\n");
>  
>      for ( ;; )



  reply	other threads:[~2024-07-15  8:52 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-12 16:22 [PATCH v2 0/8] RISCV device tree mapping Oleksii Kurochko
2024-07-12 16:22 ` [PATCH v6 1/8] xen/device-tree: Move Arm's setup.c bootinfo functions to common Oleksii Kurochko
2024-07-15  8:36   ` Jan Beulich
2024-07-15 10:15   ` Michal Orzel
2024-07-15 13:42     ` Oleksii
2024-07-12 16:22 ` [PATCH v6 2/8] xen/common: Move Arm's bootfdt.c " Oleksii Kurochko
2024-07-12 16:22 ` [PATCH v2 3/8] xen/riscv: enable CONFIG_HAS_DEVICE_TREE Oleksii Kurochko
2024-07-15  8:40   ` Jan Beulich
2024-07-12 16:22 ` [PATCH v2 4/8] xen/riscv: setup fixmap mapping Oleksii Kurochko
2024-07-21  8:46   ` Julien Grall
2024-07-22 14:31     ` Oleksii
2024-07-22 14:44       ` Julien Grall
2024-07-23 12:58     ` oleksii.kurochko
2024-07-23 13:32       ` Julien Grall
2024-07-23 13:27     ` oleksii.kurochko
2024-07-23 13:33       ` Julien Grall
2024-07-23 13:38         ` oleksii.kurochko
2024-07-22 12:42   ` Jan Beulich
2024-07-22 14:36     ` Oleksii
2024-07-22 15:25       ` Jan Beulich
2024-07-22 17:04         ` oleksii.kurochko
2024-07-23 13:34           ` oleksii.kurochko
2024-07-12 16:22 ` [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header Oleksii Kurochko
2024-07-21  8:51   ` Julien Grall
2024-07-22 12:58     ` Jan Beulich
2024-07-22 14:57       ` Julien Grall
2024-07-22 14:40     ` Oleksii
2024-07-22 12:54   ` Jan Beulich
2024-07-22 14:44     ` Oleksii Kurochko
2024-07-22 14:48       ` Julien Grall
2024-07-22 17:09         ` Oleksii Kurochko
2024-07-22 17:21           ` Julien Grall
2024-07-23  8:02             ` Oleksii Kurochko
2024-07-23  8:36               ` Jan Beulich
2024-07-23  8:55                 ` oleksii.kurochko
2024-07-23 10:02                   ` Jan Beulich
2024-07-23 15:36                     ` oleksii.kurochko
2024-07-23 15:49                       ` Julien Grall
2024-07-23 17:25                         ` oleksii.kurochko
2024-07-23 17:28                           ` oleksii.kurochko
2024-07-23 18:44                             ` Julien Grall
2024-07-12 16:22 ` [PATCH v2 6/8] xen/riscv: introduce generic Xen page table handling Oleksii Kurochko
2024-07-21  9:02   ` Julien Grall
2024-07-22  6:59     ` Jan Beulich
2024-07-22 14:51     ` Oleksii
2024-07-12 16:22 ` [PATCH v2 7/8] xen/riscv: select CONFIG_GENREIC_PT Oleksii Kurochko
2024-07-12 16:22 ` [PATCH v2 8/8] xen/riscv: introduce early_fdt_map() Oleksii Kurochko
2024-07-15  8:52   ` Jan Beulich [this message]
2024-07-15 13:58     ` Oleksii
2024-07-15 14:58       ` Jan Beulich
2024-07-15 15:00         ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc8d2e10-0898-4f5a-b296-1bc7f528bb77@suse.com \
    --to=jbeulich@suse.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bobbyeshleman@gmail.com \
    --cc=connojdavis@gmail.com \
    --cc=julien@xen.org \
    --cc=oleksii.kurochko@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.