All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Connor Davis <connojdavis@gmail.com>
Cc: Bobby Eshleman <bobbyeshleman@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-next 5/6] xen: Add files needed for minimal riscv build
Date: Fri, 12 Mar 2021 18:09:13 +0100	[thread overview]
Message-ID: <84f490e8-7035-565d-4b20-6e46ccc800f2@suse.com> (raw)
In-Reply-To: <7652ce3486c026a3a9f7d850170ea81ba8a18bdb.1614265718.git.connojdavis@gmail.com>

On 25.02.2021 16:24, Connor Davis wrote:
> --- /dev/null
> +++ b/xen/include/public/arch-riscv.h
> @@ -0,0 +1,183 @@
> +/******************************************************************************
> + * arch-riscv.h
> + *
> + * Guest OS interface to RISC-V Xen.
> + * Initially based on the ARM implementation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright 2019 (C) Alistair Francis <alistair.francis@wdc.com>
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_RISCV_H__
> +#define __XEN_PUBLIC_ARCH_RISCV_H__
> +
> +#include <xen/types.h>
> +
> +#define  int64_aligned_t  int64_t __attribute__((aligned(8)))
> +#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
> +
> +#ifndef __ASSEMBLY__
> +#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
> +    typedef union { type *p; unsigned long q; }                 \
> +        __guest_handle_ ## name;                                \
> +    typedef union { type *p; uint64_aligned_t q; }              \
> +        __guest_handle_64_ ## name
> +
> +/*
> + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
> + * in a struct in memory. On rv64 it is 8 bytes long and 8-byte aligned.
> + *
> + * XEN_GUEST_HANDLE_PARAM represents a guest pointer, when passed as a
> + * hypercall argument. It is 4 bytes on rv32 and 8 bytes on rv64.
> + */
> +#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
> +    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
> +    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> +#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
> +#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> +#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> +#define set_xen_guest_handle_raw(hnd, val)                  \
> +    do {                                                    \
> +        typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
> +        _sxghr_tmp->q = 0;                                  \
> +        _sxghr_tmp->p = val;                                \
> +    } while ( 0 )
> +#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
> +
> +#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> +# define __DECL_REG(n64, n32) union {          \
> +        uint64_t n64;                          \
> +        uint32_t n32;                          \
> +    }
> +#else
> +/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
> +#define __DECL_REG(n64, n32) uint64_t n64
> +#endif
> +
> +struct vcpu_guest_core_regs
> +{
> +    unsigned long zero;
> +    unsigned long ra;
> +    unsigned long sp;
> +    unsigned long gp;
> +    unsigned long tp;
> +    unsigned long t0;
> +    unsigned long t1;
> +    unsigned long t2;
> +    unsigned long s0;
> +    unsigned long s1;
> +    unsigned long a0;
> +    unsigned long a1;
> +    unsigned long a2;
> +    unsigned long a3;
> +    unsigned long a4;
> +    unsigned long a5;
> +    unsigned long a6;
> +    unsigned long a7;
> +    unsigned long s2;
> +    unsigned long s3;
> +    unsigned long s4;
> +    unsigned long s5;
> +    unsigned long s6;
> +    unsigned long s7;
> +    unsigned long s8;
> +    unsigned long s9;
> +    unsigned long s10;
> +    unsigned long s11;
> +    unsigned long t3;
> +    unsigned long t4;
> +    unsigned long t5;
> +    unsigned long t6;

Please avoid use of "unsigned long" in the public headers. Consumers,
potentially even cross-bitness or cross-arch ones, may have a different
view on what unsigned long is. uint<N>_t wants using here, and if you
mean to abstract 32-bit and 64-bit right away, then something like a
register_t typedef may want introducing.

Also iirc all the integer registers can also be referred to as x<N>,
in which case it might be nice to allow for both names (in a union).
You have a __DECL_REG() further up, but you don't appear to be using
it ...

> --- a/xen/include/public/hvm/save.h
> +++ b/xen/include/public/hvm/save.h
> @@ -106,6 +106,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
>  #include "../arch-x86/hvm/save.h"
>  #elif defined(__arm__) || defined(__aarch64__)
>  #include "../arch-arm/hvm/save.h"
> +#elif defined(__riscv)
> +#include "../arch-riscv/hvm/save.h"

Does the compiler not also provide __riscv__? If it does, using it
here (and elsewhere) would fit better with the existing logic.

Jan


  parent reply	other threads:[~2021-03-12 17:09 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 15:23 [PATCH for-next 0/6] Minimal build for RISCV Connor Davis
2021-02-25 15:24 ` [PATCH for-next 1/6] xen/char: Default HAS_NS16550 to y only for X86 and ARM Connor Davis
2021-02-25 15:24 ` [PATCH for-next 2/6] xen/common: Guard iommu symbols with CONFIG_HAS_PASSTHROUGH Connor Davis
2021-02-25 15:45   ` Jan Beulich
2021-02-26  2:54     ` Connor Davis
2021-02-26  7:41       ` Jan Beulich
2021-02-25 15:24 ` [PATCH for-next 3/6] xen/sched: Fix build when NR_CPUS == 1 Connor Davis
2021-02-25 15:50   ` Jan Beulich
2021-02-26  3:08     ` Connor Davis
2021-02-26  8:31       ` Jan Beulich
2021-02-26 16:49         ` Dario Faggioli
2021-02-27  4:17         ` Connor Davis
2021-02-25 22:55   ` Bob Eshleman
2021-02-26  3:01     ` Connor Davis
2021-02-26 15:21       ` Bob Eshleman
2021-02-25 15:24 ` [PATCH for-next 4/6] xen: Fix build when !CONFIG_GRANT_TABLE Connor Davis
2021-02-25 15:53   ` Jan Beulich
2021-02-26  3:36     ` Connor Davis
2021-02-25 15:24 ` [PATCH for-next 5/6] xen: Add files needed for minimal riscv build Connor Davis
2021-02-25 23:14   ` Andrew Cooper
2021-02-26  1:06     ` Stefano Stabellini
2021-02-27  4:05       ` Connor Davis
2021-02-26  3:29     ` Connor Davis
2021-02-26 15:30     ` Bob Eshleman
2021-02-26 15:55       ` Andrew Cooper
2021-02-26 16:21         ` Bob Eshleman
2021-02-26 16:56           ` Andrew Cooper
2021-03-12 17:01   ` Jan Beulich
2021-03-12 17:09   ` Jan Beulich [this message]
2021-05-14  3:25     ` Connor Davis
2021-02-25 15:24 ` [PATCH for-next 6/6] automation: add container for riscv64 builds Connor Davis
2021-02-26  0:31   ` Stefano Stabellini
2021-02-26  6:15     ` Connor Davis
2021-02-26 15:54 ` [PATCH for-next 0/6] Minimal build for RISCV Bob Eshleman

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=84f490e8-7035-565d-4b20-6e46ccc800f2@suse.com \
    --to=jbeulich@suse.com \
    --cc=aisaila@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bobbyeshleman@gmail.com \
    --cc=connojdavis@gmail.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=ppircalabu@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas@tklengyel.com \
    --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.