[PATCH 3/3] RISC-V: Ensure Zicbom has a valid block size

[Conor Dooley]

On Mon, Oct 24, 2022 at 10:35:22AM +0200, Andrew Jones wrote:
> On Mon, Oct 24, 2022 at 09:17:50AM +0100, Conor Dooley wrote:
> > My initial thought here was along the lines of "why care about the
> > issues when it's not enabled", but I went to get some caffeine before
> > replying and had a change of heart.
> > IMO, it'd be good to tell people that their DT doesn't describe their
> > hardware properly when it's gone wrong in a way that we cannot really
> > spot via dtbs_check etc. I'll go away and have a think about whether
> > the DT checks can force cbom-block-size if zicbom is in the isa string,
> > but I'm not sure if that sort of conditional is checkable.
> > If either of these error cases are hit (regardless of whether you set
> > CONFIG_RISCV_ISA_ZICBOM) then it'd cause issues for KVM right? That
> > would imply printing unconditionally to me.
> 
> Yes and no. KVM won't have any issues as it won't see Zicbom in the ISA
> bitmap and therefore won't consider offering it to guests. However, it
> could have offered it to guests, if only the DT was fixed, so I agree,
> it's best to unconditionally complain when we see something wrong.

Yeah, that's pretty much what I was getting at. By "KVM having issues" I
meant that without disabling Zicbom, as your patch does, KVM would carry
on & offer Zicbom with the "bad" cbom block size to guests. Following
that line of thought, we'd then want to disable Zicbom & complain no
matter the state of the kconfig symbol so that there'd be info there for
the folks running a non-Zicbom kernel but trying to use Zicbom in their
guest.

> 
> > The level at which to
> > actually emit that is beyond the scope of what I care about though ;)
> 
> This stackoverflow.com thread indicates I should use 'error'.
> https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels

Yeah, on the basis of that thread error does seem appropriate.