Re: [PATCH v3 15/34] xen/riscv: introduce atomic.h

[Oleksii <oleksii.kurochko@xxxxxxxxx>]

On Tue, 2024-01-23 at 11:30 +0100, Jan Beulich wrote:
> On 23.01.2024 11:21, Oleksii wrote:
> > On Mon, 2024-01-22 at 17:56 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/include/asm/fence.h
> > > > @@ -0,0 +1,13 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > > +#ifndef _ASM_RISCV_FENCE_H
> > > > +#define _ASM_RISCV_FENCE_H
> > > > +
> > > > +#ifdef CONFIG_SMP
> > > > +#define RISCV_ACQUIRE_BARRIER          "\tfence r , rw\n"
> > > > +#define RISCV_RELEASE_BARRIER          "\tfence rw,  w\n"
> > > > +#else
> > > > +#define RISCV_ACQUIRE_BARRIER
> > > > +#define RISCV_RELEASE_BARRIER
> > > > +#endif
> > > 
> > > Do you really care about the !SMP case? On x86 at least we
> > > stopped
> > > special-
> > > casing that configuration many years ago (the few cases where for
> > > typically
> > > build reasons it matters, using CONFIG_NR_CPUS is sufficient). If
> > > you
> > > care
> > > about it, there needs to be somewhere you actually #define
> > > CONFIG_SMP.
> > Can't we use instead of CONFIG_SMP - CONFIG_NR_CPUS?
> 
> You can. Question is whether there's a point in doing so. Do you
> expect people to actually want to run Xen on single-CPU systems?
> They're generally not overly well suited for virtualization ...
Just to clarify.

Do you mean physically single based CPU?
Then I don't expect to run Xen on such systems and it is not nesessary
to define *_BARRIER in this case. Should we have to add build error
notification that we don't support single-CPU systems in this header?

If you are speaking about we have ,let it be, 4 CPUs and only 1 CPU is
currently supported by Xen then it still makes sense.

~ Oleksii