|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1 5/6] xen/riscv: implement relocate_fdt()
On 27.11.2024 13:50, Oleksii Kurochko wrote:
> relocate_fdt() relocates FDT to Xen heap instead of using early mapping
> as it is expected that discard_initial_modules() ( is supposed to call
> in the future ) discards the FDT boot module and remove_early_mappings()
> destroys the early mapping.
>
> To implement that the following things are introduced as they are called
> by internals of xmalloc_bytes() which is used in relocate_fdt():
> 1. As RISC-V may have non-coherent access for RAM ( f.e., in case
> of non-coherent IO devices ) flush_page_to_ram() is implemented
> to ensure that cache and RAM are consistent for such platforms.
This is a detail of the page allocator, yes. It can then be viewed as also
a detail of xmalloc() et al, but I consider the wording a little misleading.
> 2. copy_from_paddr() to copy FDT from a physical address to allocated
> by xmalloc_bytes() in Xen heap.
This doesn't look to be related to the internals of xmalloc() et al.
> 3. virt_to_page() to convert virtual address to page. Also introduce
> directmap_virt_end to check that VA argument of virt_to_page() is
> inside directmap region.
This is a need of free_xenheap_pages(), yes; see remark on point 1.
> @@ -148,8 +150,12 @@ static inline void *page_to_virt(const struct page_info
> *pg)
> /* Convert between Xen-heap virtual addresses and page-info structures. */
> static inline struct page_info *virt_to_page(const void *v)
> {
> - BUG_ON("unimplemented");
> - return NULL;
> + unsigned long va = (unsigned long)v;
> +
> + ASSERT(va >= DIRECTMAP_VIRT_START);
> + ASSERT(va <= directmap_virt_end);
Why the difference compared to virt_to_maddr()?
Also recall my comment on one of your earlier series, regarding inclusive
vs exclusive ranges. Can that please be sorted properly as a prereq, to
avoid extending the inconsistency?
> @@ -172,10 +173,15 @@ static inline void invalidate_icache(void)
> #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
> #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
>
> -/* TODO: Flush the dcache for an entire page. */
> static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
> {
> - BUG_ON("unimplemented");
> + void *v = map_domain_page(_mfn(mfn));
const void *?
> + clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
> + unmap_domain_page(v);
> +
> + if ( sync_icache )
> + invalidate_icache();
> }
>
> /* Write a pagetable entry. */
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -419,6 +419,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
> }
>
> vaddr_t __ro_after_init directmap_virt_start = DIRECTMAP_VIRT_START;
> +vaddr_t __ro_after_init directmap_virt_end;
If the variable is needed (see above) it pretty certainly wants an
initializer, too.
> @@ -26,6 +27,46 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
> unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> __aligned(STACK_SIZE);
>
> +/**
> + * copy_from_paddr - copy data from a physical address
> + * @dst: destination virtual address
> + * @paddr: source physical address
> + * @len: length to copy
> + */
> +void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
Without a declaration in a header this function ought to be static.
> +{
> + void *src = (void *)FIXMAP_ADDR(FIX_MISC);
const void *
> + while (len) {
Nit: Style.
> + unsigned long l, s;
> +
> + s = paddr & (PAGE_SIZE - 1);
> + l = min(PAGE_SIZE - s, len);
Make these the variables' initializers?
> + set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
> + memcpy(dst, src + s, l);
> + clean_dcache_va_range(dst, l);
Why is this necessary here? You're copying to plain RAM that Xen alone
is using.
> +/* Relocate the FDT in Xen heap */
> +static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size)
This function having no caller will - aiui - mean build breakage at
this point of the series.
> +{
> + void *fdt = xmalloc_bytes(dtb_size);
New code ought to be using xvmalloc() et al. Unless there's a firm
reason not to.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |