Re: [PATCH v3 4/5] xen: Add files needed for minimal riscv build

[Connor Davis <connojdavis@gmail.com>]

On 5/14/21 3:53 PM, Bob Eshleman wrote:
> On 5/14/21 11:53 AM, Connor Davis wrote:
>> Add arch-specific makefiles and configs needed to build for
>> riscv64. Also add a minimal head.S that is a simple infinite loop.
>> head.o can be built with
>>
>> $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen TARGET=head.o
>>
> I recently realized that the Linux kernel build uses `ARCH=riscv`
> with 32 vs 64 being differentiated by Kconfig opts (and __riscv_xlen).
> I think `riscv64` was inherited by `arm64`.  This is something I'd
> like to eventually change the Xen build to (i.e.,
> `XEN_TARGET_ARCH=riscv make`) would it be possible for us to get that
> in this series?

Sure, I can do that

>
>> diff --git a/xen/include/asm-riscv/config.h b/xen/include/asm-riscv/config.h
>> new file mode 100644
>> index 0000000000..84cb436dc1
>> --- /dev/null
>> +++ b/xen/include/asm-riscv/config.h
>> @@ -0,0 +1,110 @@
>> +/******************************************************************************
>> + * config.h
>> + *
>> + * A Linux-style configuration list.
>> + */
>> +
>> +#ifndef __RISCV_CONFIG_H__
>> +#define __RISCV_CONFIG_H__
>> +
> ...
>
>> +
>> +#ifdef CONFIG_RISCV_64
>> +
>> +/*
>> + * RISC-V Layout:
>> + *   0x0000000000000000 - 0x0000003fffffffff (256GB, L2 slots [0-255])
>> + *     Unmapped
>> + *   0x0000004000000000 - 0xffffffbfffffffff
>> + *     Inaccessible: sv39 only supports 39-bit sign-extended VAs.
>> + *   0xffffffc000000000 - 0xffffffc0001fffff (2MB, L2 slot [256])
>> + *     Unmapped
>> + *   0xffffffc000200000 - 0xffffffc0003fffff (2MB, L2 slot [256])
>> + *     Xen text, data, bss
>> + *   0xffffffc000400000 - 0xffffffc0005fffff (2MB, L2 slot [256])
>> + *     Fixmap: special-purpose 4K mapping slots
>> + *   0xffffffc000600000 - 0xffffffc0009fffff (4MB, L2 slot [256])
>> + *     Early boot mapping of FDT
>> + *   0xffffffc000a00000 - 0xffffffc000bfffff (2MB, L2 slot [256])
>> + *     Early relocation address, used when relocating Xen and later
>> + *     for livepatch vmap (if compiled in)
>> + *   0xffffffc040000000 - 0xffffffc07fffffff (1GB, L2 slot [257])
>> + *     VMAP: ioremap and early_ioremap
>> + *   0xffffffc080000000 - 0xffffffc13fffffff (3GB, L2 slots [258..260])
>> + *     Unmapped
>> + *   0xffffffc140000000 - 0xffffffc1bfffffff (2GB, L2 slots [261..262])
>> + *     Frametable: 48 bytes per page for 133GB of RAM
>> + *   0xffffffc1c0000000 - 0xffffffe1bfffffff (128GB, L2 slots [263..390])
>> + *     1:1 direct mapping of RAM
>> + *   0xffffffe1c0000000 - 0xffffffffffffffff (121GB, L2 slots [391..511])
>> + *     Unmapped
>> + */
>> +
> What is the benefit of moving the layout up to 0xffffffc000000000?

I thought it made the most sense to use the upper half since Xen is 
privileged

and privileged code is typically mapped in the upper half, at least on 
x86. I'm happy to

move it down if that would be preferred.


Thanks,

Connor