Re: [PATCH 1/2] target/riscv: fence.i: update decode pattern

[Peter Maydell]

On Fri, 12 Aug 2022 at 15:11, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
>
> On Fri, 12 Aug 2022 at 16:01, Andrew Jones <ajones@ventanamicro.com> wrote:
> >
> > > Update the decode pattern to reflect the specification.
> >
> > I got hung-up on this for a bit since there isn't any "must-be-0" fields,
>
> Please refer to '“Zifencei” Instruction-Fetch Fence, Version 2.0' in
> the specification.
> The encoding diagram clearly states 0 for imm[11:0], 0 for rs1 and 0 for rd.
>
> However, there is an explanatory paragraph below (unfortunately, it is
> not clear whether this is normative or informative):

> > The unused fields in the FENCE.I instruction, imm[11:0], rs1, and rd, are 
> > reserved for finer-grain fences in future extensions. For forward 
> > compatibility, base implementations shall ignore these fields, and standard 
> > software shall zero these fields.

That's pretty clear that this patch is wrong, then -- QEMU
is an implementation, and so we must ignore these fields.
Otherwise when a future version of the spec defines a finer-grain
fence instruction in this part of the encoding space, older
QEMU will incorrectly make software that uses it crash.

If you think the spec is insufficiently clear about whether that
is normative then that would be something to raise with the
spec authors, preferably before anybody builds hardware that
enforces must-be-zeroes on these fields...

thanks
-- PMM