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>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 31/34] xen/riscv: add minimal stuff to mm.h to build full Xen
Date: Tue, 23 Jan 2024 14:03:49 +0100	[thread overview]
Message-ID: <d347c4d9-e93b-4937-8e33-e5fbbdcd6bfb@suse.com> (raw)
In-Reply-To: <4411f6af38586074b347cd6005f19f9c670faa74.1703255175.git.oleksii.kurochko@gmail.com>

On 22.12.2023 16:13, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
> Changes in V3:
>  - update the commit message

??? (yet again)

> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -3,8 +3,251 @@
>  #ifndef _ASM_RISCV_MM_H
>  #define _ASM_RISCV_MM_H
>  
> +#include <public/xen.h>
> +#include <xen/pdx.h>
> +#include <xen/types.h>
> +
> +#include <asm/page.h>
>  #include <asm/page-bits.h>
>  
> +#define paddr_to_pdx(pa)    mfn_to_pdx(maddr_to_mfn(pa))
> +#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
> +#define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
> +#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
> +#define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
> +#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)va))
> +#define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))

Everything you have above ...

> +#define paddr_to_pdx(pa)    mfn_to_pdx(maddr_to_mfn(pa))
> +#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
> +#define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
> +#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
> +#define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
> +#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)va))
> +#define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))

... appears a 2nd time right afterwards.

> +#define virt_to_maddr(va) ((paddr_t)((vaddr_t)(va) & PADDR_MASK))
> +#define maddr_to_virt(pa) ((void *)((paddr_t)(pa) | DIRECTMAP_VIRT_START))
> +
> +/* Convert between Xen-heap virtual addresses and machine frame numbers. */
> +#define __virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT)
> +#define __mfn_to_virt(mfn) maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT)

These would imo better use maddr_to_mfn() and mfn_to_maddr(), rather than
kind of open-coding them. The former could also use PFN_DOWN() as an
alternative.

> +/* Convert between Xen-heap virtual addresses and page-info structures. */
> +static inline struct page_info *virt_to_page(const void *v)
> +{
> +    BUG();
> +    return NULL;
> +}
> +
> +/*
> + * We define non-underscored wrappers for above conversion functions.
> + * These are overriden in various source files while underscored version
> + * remain intact.
> + */
> +#define virt_to_mfn(va)     __virt_to_mfn(va)
> +#define mfn_to_virt(mfn)    __mfn_to_virt(mfn)

Is this really still needed? Would be pretty nice if in a new port we
could get to start cleanly right away (i.e. by not needing per-file
overrides, but using type-safe expansions here right away).

> +struct page_info
> +{
> +    /* Each frame can be threaded onto a doubly-linked list. */
> +    struct page_list_entry list;
> +
> +    /* Reference count and various PGC_xxx flags and fields. */
> +    unsigned long count_info;
> +
> +    /* Context-dependent fields follow... */
> +    union {
> +        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
> +        struct {
> +            /* Type reference count and various PGT_xxx flags and fields. */
> +            unsigned long type_info;
> +        } inuse;
> +        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
> +        union {
> +            struct {
> +                /*
> +                 * Index of the first *possibly* unscrubbed page in the buddy.
> +                 * One more bit than maximum possible order to accommodate
> +                 * INVALID_DIRTY_IDX.
> +                 */
> +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
> +                unsigned long first_dirty:MAX_ORDER + 1;
> +
> +                /* Do TLBs need flushing for safety before next page use? */
> +                bool need_tlbflush:1;
> +
> +#define BUDDY_NOT_SCRUBBING    0
> +#define BUDDY_SCRUBBING        1
> +#define BUDDY_SCRUB_ABORT      2
> +                unsigned long scrub_state:2;
> +            };
> +
> +                unsigned long val;
> +            } free;

Indentation is wrong (and thus misleading) for these two lines.

> +
> +    } u;

Nit: I don't see the value of the trailing blank line inside the
union.

> +    union {
> +        /* Page is in use, but not as a shadow. */

I question the appicability of "shadow" here.

> +        struct {
> +            /* Owner of this page (zero if page is anonymous). */
> +            struct domain *domain;
> +        } inuse;
> +
> +        /* Page is on a free list. */
> +        struct {
> +            /* Order-size of the free chunk this page is the head of. */
> +            unsigned int order;
> +        } free;
> +
> +    } v;
> +
> +    union {
> +        /*
> +         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
> +         * Only valid for: a) free pages, and b) pages with zero type count
> +         */
> +        uint32_t tlbflush_timestamp;
> +    };
> +    uint64_t pad;
> +};
> +
> +#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
> +
> +/* PDX of the first page in the frame table. */
> +extern unsigned long frametable_base_pdx;

From this I conclude memory on RISC-V systems may not start at (or near) 0?

> +/* Convert between machine frame numbers and page-info structures. */
> +#define mfn_to_page(mfn)                                            \
> +    (frame_table + (mfn_to_pdx(mfn) - frametable_base_pdx))
> +#define page_to_mfn(pg)                                             \
> +    pdx_to_mfn((unsigned long)((pg) - frame_table) + frametable_base_pdx)
> +
> +static inline void *page_to_virt(const struct page_info *pg)
> +{
> +    return mfn_to_virt(mfn_x(page_to_mfn(pg)));
> +}
> +
> +/*
> + * Common code requires get_page_type and put_page_type.
> + * We don't care about typecounts so we just do the minimum to make it
> + * happy.
> + */
> +static inline int get_page_type(struct page_info *page, unsigned long type)
> +{
> +    return 1;
> +}
> +
> +static inline void put_page_type(struct page_info *page)
> +{
> +}
> +
> +static inline void put_page_and_type(struct page_info *page)
> +{
> +    put_page_type(page);
> +    put_page(page);
> +}
> +
> +/*
> + * RISC-V does not have an M2P, but common code expects a handful of
> + * M2P-related defines and functions. Provide dummy versions of these.
> + */
> +#define INVALID_M2P_ENTRY        (~0UL)
> +#define SHARED_M2P_ENTRY         (~0UL - 1UL)
> +#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
> +
> +/* Xen always owns P2M on RISC-V */
> +#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn), (void)(pfn); } while (0)

Nit: Stray blank again after cast.

> +#define mfn_to_gfn(d, mfn) ((void)(d), _gfn(mfn_x(mfn)))

What's the relation of the comment with these two #define-s?

> +#define PDX_GROUP_SHIFT (16 + 5)
> +
> +static inline unsigned long domain_get_maximum_gpfn(struct domain *d)
> +{
> +    BUG();
> +    return 0;
> +}
> +
> +static inline long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +    BUG();
> +    return 0;
> +}
> +
> +/*
> + * On RISCV, all the RAM is currently direct mapped in Xen.
> + * Hence return always true.
> + */
> +static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
> +{
> +    return true;
> +}
> +
> +#define PG_shift(idx)   (BITS_PER_LONG - (idx))
> +#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
> +
> +#define PGT_none          PG_mask(0, 1)  /* no special uses of this page   */
> +#define PGT_writable_page PG_mask(1, 1)  /* has writable mappings?         */
> +#define PGT_type_mask     PG_mask(1, 1)  /* Bits 31 or 63.                 */
> +
> + /* Count of uses of this frame as its current type. */
> +#define PGT_count_width   PG_shift(2)
> +#define PGT_count_mask    ((1UL<<PGT_count_width)-1)

Nit: Style (missing blanks around binary operators). Also a few more
times further down.

> +/*
> + * Page needs to be scrubbed. Since this bit can only be set on a page that is
> + * free (i.e. in PGC_state_free) we can reuse PGC_allocated bit.
> + */
> +#define _PGC_need_scrub   _PGC_allocated
> +#define PGC_need_scrub    PGC_allocated
> +
> +//  /* Cleared when the owning guest 'frees' this page. */

Why a commented out comment?

> +#define _PGC_allocated    PG_shift(1)
> +#define PGC_allocated     PG_mask(1, 1)
> +  /* Page is Xen heap? */
> +#define _PGC_xen_heap     PG_shift(2)
> +#define PGC_xen_heap      PG_mask(1, 2)
> +/* Page is broken? */
> +#define _PGC_broken       PG_shift(7)
> +#define PGC_broken        PG_mask(1, 7)
> + /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */

Can similar comments in this block please all be similarly indented
(or not)?

> +#define PGC_state         PG_mask(3, 9)
> +#define PGC_state_inuse   PG_mask(0, 9)
> +#define PGC_state_offlining PG_mask(1, 9)
> +#define PGC_state_offlined PG_mask(2, 9)
> +#define PGC_state_free    PG_mask(3, 9)
> +// #define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)

???

> +/* Count of references to this frame. */
> +#define PGC_count_width   PG_shift(9)
> +#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
> +
> +#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)

And here it then "properly" appears?

> +#define _PGC_extra        PG_shift(10)
> +#define PGC_extra         PG_mask(1, 10)
> +
> +#define is_xen_heap_page(page) ((page)->count_info & PGC_xen_heap)
> +#define is_xen_heap_mfn(mfn) \
> +    (mfn_valid(mfn) && is_xen_heap_page(mfn_to_page(mfn)))
> +
> +#define is_xen_fixed_mfn(mfn)                                   \
> +    ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) &&           \
> +     (mfn_to_maddr(mfn) <= virt_to_maddr((vaddr_t)_end - 1)))

Why does _start need prefixing wuth & and _end prefixing with a cast?
First and foremost both want to be consistent. And then preferably
with as little extra clutter as possible.

> +#define page_get_owner(_p)    (_p)->v.inuse.domain
> +#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
> +
> +/* TODO: implement */
> +#define mfn_valid(mfn) ({ (void) (mfn); 0; })
> +
> +#define mfn_to_gfn(d, mfn) ((void)(d), _gfn(mfn_x(mfn)))

This appeared further up already.

> +#define domain_set_alloc_bitsize(d) ((void)0)

Better ((void)(d)) ? And then ...

> +#define domain_clamp_alloc_bitsize(d, b) (b)

... ((void)(d), (b)) here?

Jan


  parent reply	other threads:[~2024-01-23 13:04 UTC|newest]

Thread overview: 146+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-22 15:12 [PATCH v3 00/34] Enable build of full Xen for RISC-V Oleksii Kurochko
2023-12-22 15:12 ` [PATCH v3 01/34] xen/riscv: disable unnecessary configs Oleksii Kurochko
2023-12-22 15:12 ` [PATCH v3 02/34] xen/riscv: use some asm-generic headers Oleksii Kurochko
2023-12-22 15:12 ` [PATCH v3 03/34] xen: add support in public/hvm/save.h for PPC and RISC-V Oleksii Kurochko
2024-01-04 11:01   ` Jan Beulich
2024-01-08 14:46     ` Oleksii
2023-12-22 15:12 ` [PATCH v3 04/34] xen/riscv: introduce cpufeature.h Oleksii Kurochko
2023-12-22 15:12 ` [PATCH v3 05/34] xen/riscv: introduce guest_atomics.h Oleksii Kurochko
2024-01-11 15:57   ` Jan Beulich
2024-01-15  9:26     ` Oleksii
2023-12-22 15:12 ` [PATCH v3 06/34] xen: avoid generation of empty asm/iommu.h Oleksii Kurochko
2024-01-04 11:04   ` Jan Beulich
2024-01-08 14:47     ` Oleksii
2023-12-22 15:12 ` [PATCH v3 07/34] xen/asm-generic: introdure nospec.h Oleksii Kurochko
2024-01-04 11:06   ` Jan Beulich
2024-01-04 11:13     ` Andrew Cooper
2024-01-04 12:03       ` Jan Beulich
2024-01-08 14:58     ` Oleksii
2024-01-05 19:02   ` Shawn Anastasio
2023-12-22 15:12 ` [PATCH v3 08/34] xen/riscv: introduce setup.h Oleksii Kurochko
2023-12-22 15:12 ` [PATCH v3 09/34] xen/riscv: introduce system.h Oleksii Kurochko
2024-01-11 16:00   ` Jan Beulich
2024-01-15  9:28     ` Oleksii
2023-12-22 15:12 ` [PATCH v3 10/34] xen/riscv: introduce bitops.h Oleksii Kurochko
2024-01-15 16:44   ` Jan Beulich
2024-01-16 13:06     ` Oleksii
2024-01-16 13:24       ` Jan Beulich
2024-01-17 11:13         ` Oleksii
2024-01-17 11:17           ` Jan Beulich
2024-01-17 11:37             ` Oleksii
2024-01-17 13:42               ` Jan Beulich
2024-01-18  9:43                 ` Oleksii
2024-01-18 11:01                   ` Jan Beulich
2024-01-19  9:16                     ` Oleksii
2024-01-19  9:20                       ` Jan Beulich
2024-01-18 11:03   ` Jan Beulich
2024-01-19  9:09     ` Oleksii
2024-01-19  9:14       ` Jan Beulich
2024-01-19  9:30         ` Oleksii
2023-12-22 15:12 ` [PATCH v3 11/34] xen/riscv: introduce flushtlb.h Oleksii Kurochko
2023-12-22 15:12 ` [PATCH v3 12/34] xen/riscv: introduce smp.h Oleksii Kurochko
2024-01-11 16:36   ` Jan Beulich
2024-01-15  9:35     ` Oleksii
2023-12-22 15:12 ` [PATCH v3 13/34] xen/riscv: introduce cmpxchg.h Oleksii Kurochko
2024-01-22 16:27   ` Jan Beulich
2024-01-23 10:15     ` Oleksii
2024-01-23 10:28       ` Jan Beulich
2024-01-23 12:18         ` Oleksii
2024-01-23 13:27           ` Jan Beulich
2024-01-24  9:15             ` Oleksii
2024-01-30 14:57     ` Oleksii
2024-01-30 15:05       ` Jan Beulich
2024-01-30 15:16         ` Oleksii
2023-12-22 15:12 ` [PATCH v3 14/34] xen/riscv: introduce io.h Oleksii Kurochko
2024-01-15 16:57   ` Jan Beulich
2024-01-16 15:20     ` Oleksii
2024-01-16 16:09       ` Jan Beulich
2024-01-31 17:30         ` Oleksii
2023-12-22 15:12 ` [PATCH v3 15/34] xen/riscv: introduce atomic.h Oleksii Kurochko
2024-01-22 16:56   ` Jan Beulich
2024-01-23 10:21     ` Oleksii
2024-01-23 10:30       ` Jan Beulich
2024-01-23 12:24         ` Oleksii
2024-01-23 13:30           ` Jan Beulich
2024-01-24  9:23             ` Oleksii
2024-01-24 11:19               ` Jan Beulich
2024-01-24 14:56                 ` Oleksii
2023-12-22 15:13 ` [PATCH v3 16/34] xen/lib: introduce generic find next bit operations Oleksii Kurochko
2024-01-23 11:14   ` Jan Beulich
2024-01-23 12:34     ` Oleksii
2024-01-23 13:37       ` Jan Beulich
2024-01-24  9:34         ` Oleksii
2024-01-24 11:24           ` Jan Beulich
2024-01-24 15:04             ` Oleksii
2024-01-24 15:32               ` Jan Beulich
2024-01-26  9:44         ` Oleksii
2024-01-26  9:48           ` Jan Beulich
2024-01-26  9:56             ` Oleksii
2023-12-22 15:13 ` [PATCH v3 17/34] xen/riscv: add compilation of generic find-next-bit.c Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 18/34] xen/riscv: introduce domain.h Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 19/34] xen/riscv: introduce guest_access.h Oleksii Kurochko
2024-01-23 11:16   ` Jan Beulich
2023-12-22 15:13 ` [PATCH v3 20/34] xen/riscv: introduce irq.h Oleksii Kurochko
2024-01-23 11:18   ` Jan Beulich
2024-01-23 12:25     ` Oleksii
2023-12-22 15:13 ` [PATCH v3 21/34] xen/riscv: introduce p2m.h Oleksii Kurochko
2024-01-11 23:11   ` Shawn Anastasio
2024-01-15  9:37     ` Oleksii
2024-01-12 10:39   ` Julien Grall
2024-01-12 11:06     ` Jan Beulich
2024-01-12 11:09       ` Julien Grall
2024-01-15 10:35     ` Oleksii
2024-01-15 11:01       ` Jan Beulich
2024-01-16  9:44         ` Oleksii
2024-01-16 17:12           ` Julien Grall
2024-01-17  9:32             ` Oleksii
2023-12-22 15:13 ` [PATCH v3 22/34] xen/riscv: introduce regs.h Oleksii Kurochko
2024-01-15 17:00   ` Jan Beulich
2024-01-16  9:46     ` Oleksii
2023-12-22 15:13 ` [PATCH v3 23/34] xen/riscv: introduce time.h Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 24/34] xen/riscv: introduce event.h Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 25/34] xen/riscv: introduce monitor.h Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 26/34] xen/riscv: add definition of __read_mostly Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 27/34] xen/riscv: define an address of frame table Oleksii Kurochko
2024-01-23 11:32   ` Jan Beulich
2024-01-23 16:50     ` Oleksii
2024-01-24  8:07       ` Jan Beulich
2024-01-24 10:01         ` Oleksii
2023-12-22 15:13 ` [PATCH v3 28/34] xen/riscv: add required things to current.h Oleksii Kurochko
2024-01-23 11:35   ` Jan Beulich
2024-01-23 16:52     ` Oleksii
2023-12-22 15:13 ` [PATCH v3 29/34] xen/riscv: add minimal stuff to page.h to build full Xen Oleksii Kurochko
2024-01-23 11:36   ` Jan Beulich
2024-01-23 16:54     ` Oleksii
2024-01-24  8:09       ` Jan Beulich
2024-01-24 10:02         ` Oleksii
2023-12-22 15:13 ` [PATCH v3 30/34] xen/riscv: add minimal stuff to processor.h " Oleksii Kurochko
2024-01-23 11:39   ` Jan Beulich
2024-01-23 17:08     ` Oleksii
2024-01-24  8:19       ` Jan Beulich
2024-01-24 10:12         ` Oleksii
2024-01-24 11:27           ` Jan Beulich
2024-01-24 15:33             ` Oleksii
2024-01-24 15:38               ` Jan Beulich
2023-12-22 15:13 ` [PATCH v3 31/34] xen/riscv: add minimal stuff to mm.h " Oleksii Kurochko
2023-12-22 16:32   ` Oleksii
2023-12-22 18:16     ` Oleksii
2024-01-11 16:43     ` Jan Beulich
2024-01-15 10:36       ` Oleksii
2024-01-23 13:03   ` Jan Beulich [this message]
2024-01-23 17:27     ` Oleksii
2024-01-24  8:23       ` Jan Beulich
2024-02-02 17:30     ` Oleksii
2024-02-05  7:46       ` Jan Beulich
2024-02-05 12:49         ` Oleksii
2024-02-05 14:05           ` Jan Beulich
2024-02-05 14:40             ` Oleksii
2023-12-22 15:13 ` [PATCH v3 32/34] xen/rirscv: add minimal amount of stubs " Oleksii Kurochko
2024-01-23 13:20   ` Jan Beulich
2024-01-23 17:31     ` Oleksii
2023-12-22 15:13 ` [PATCH v3 33/34] xen/riscv: enable full Xen build Oleksii Kurochko
2023-12-22 15:13 ` [PATCH v3 34/34] xen/README: add compiler and binutils versions for RISC-V64 Oleksii Kurochko
2024-01-23 11:22   ` Jan Beulich
2024-01-23 14:49     ` Oleksii
2024-01-23 17:05       ` Jan Beulich
2024-01-23 17:34         ` Oleksii

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=d347c4d9-e93b-4937-8e33-e5fbbdcd6bfb@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=george.dunlap@citrix.com \
    --cc=julien@xen.org \
    --cc=oleksii.kurochko@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.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.