Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest

[Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>]

On 2026-09-08 17:05 +0200, Jan Beulich wrote:
> On 08.09.2026 16:58, Oleksii Kurochko wrote:
> > On 9/8/26 12:01 PM, Oleksii Kurochko wrote:
> >> On 9/7/26 5:57 PM, Baptiste Le Duc wrote:
> >>>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h
> >>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h
> >>>> @@ -109,6 +109,12 @@
> >>>>   #define SIP_SSIP            MIP_SSIP
> >>>>   #define SIP_STIP            MIP_STIP
> >>>> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */
> >>>> +#define STVEC_MODE_MASK            _UL(0x3)
> >>>> +#define STVEC_MODE_DIRECT        _UL(0x0)
> >>>> +#define STVEC_MODE_VECTORED        _UL(0x1)
> >>>> +#define STVEC_BASE_MASK            (~STVEC_MODE_MASK)
> >>> Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in
> >>> this patch (only STVEC_BASE_MASK is). Either use them where you decide
> >>> exceptions always target BASE regardless of MODE, or drop them until a
> >>> patch that needs them.
> >>
> >> IMO it is fine to introduce *_DIRECT/VECORED here as they are used 
> >> implicitly through STVEC_BASE_MASK and thereby it will be better to 
> >> introduce them here now instead of open-code them and then just update 
> >> STVEC_BASE_MASK again when *_DIRECT/VECORED will be re-introduced.
> >>
> > 
> > Oh, sorry, you are right. STVEC_MODE_DIRECT and STVEC_MODE_VECTORED are 
> > really not used here (in this implementation). I planned to do:
> > 
> > #define STVEC_MODE_MASK (STVEC_MODE_DIRECT | STVEC_MODE_VECTORED)
> > 
> > But I missed to do in that way.
> > 
> > I will update the defintion of STVEC_MODE_MASK in suggested above way.
> 
> But that's yield a mask value of 1, when you want it to be 3. That ORing
> together looks bogus to me anyway.
>
Yes I agree. It might be enough, for the moment, to only keep #define
STVEC_MODE_MASK _UL(3) and drop the others defines (even STVEC_BASE_MASK as Jan
mentioned the comment in the caller is already precise enough).
> 
> Jan
> 
>