[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 1/4] xen/riscv: add VM space layout
On 19.04.2023 17:42, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/config.h > +++ b/xen/arch/riscv/include/asm/config.h > @@ -4,6 +4,37 @@ > #include <xen/const.h> > #include <xen/page-size.h> > > +/* > + * RISC-V64 Layout: > + * > + * From the riscv-privileged doc: > + * When mapping between narrower and wider addresses, > + * RISC-V zero-extends a narrower physical address to a wider size. > + * The mapping between 64-bit virtual addresses and the 39-bit usable > + * address space of Sv39 is not based on zero-extension but instead > + * follows an entrenched convention that allows an OS to use one or > + * a few of the most-significant bits of a full-size (64-bit) virtual > + * address to quickly distinguish user and supervisor address regions. > + * > + * It means that: > + * top VA bits are simply ignored for the purpose of translating to PA. > + * > + * The similar is true for other Sv{32, 39, 48, 57}. Personally I find it odd that Sv32 is mentioned here (there's no truncation / aliasing there aiui), and that Sv39 is mentioned here again (when that's what the earlier paragraph talks about). > + * > ============================================================================ > + * Start addr | End addr | Size | VM area description > + * > ============================================================================ > + * FFFFFFFFC0000000 | FFFFFFFFC0200000 | 2 MB | Xen > + * FFFFFFFFC0200000 | FFFFFFFFC0600000 | 4 MB | FDT > + * FFFFFFFFC0600000 | FFFFFFFFC0800000 | 2 MB | Fixmap These are all L2 slot 511 aiui, which may be worth mentioning especially since the top bits don't match the top bits further down in the table (because of the aliasing). > + * .................. unused .................. This is covering slot 510, which again may be worth mentioning. > + * 0000003200000000 | 0000007f40000000 | 331 GB | Direct map(L2 slot: > 200-509) > + * 0000003100000000 | 0000003140000000 | 1 GB | Frametable(L2 slot: > 196-197) 1Gb is, if I'm not mistaken, a single L2 slot. Also assuming a 32-byte struct page_info (I don't think you'll get away with less than that, when even Arm32 requires this much), there's a mismatch between direct map and frame table size: With 4k pages, the scaling factor would be 128 if I'm not mistaken. So perhaps you really mean 3Gb here to cover for (slightly more than) the 331Gb of memory you mean to be able to map? > + * 0000003080000000 | 00000030c0000000 | 1 GB | VMAP (L2 slot: 194-195) > + * .................. unused .................. There are further unused regions between these three entries, while imo will want making explicit (for the avoidance of doubt, if nothing else). Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |