xen-devel.lists.xenproject.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).