Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type)

[Alistair Francis]

On Fri, Jul 14, 2023 at 11:14 AM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
>
>
> On 7/13/23 19:47, Conor Dooley wrote:
> > On Thu, Jul 13, 2023 at 07:35:01PM -0300, Daniel Henrique Barboza wrote:
> >> On 7/13/23 19:12, Conor Dooley wrote:
> >
> >>> And a question for you below Daniel.
> >>>
> >>> On Wed, Jul 12, 2023 at 11:14:21PM +0100, Conor Dooley wrote:
> >
> >
> >>>
> >>>> qemu-system-riscv64: warning: disabling zca extension for hart 
> >>>> 0x0000000000000000 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zca extension for hart 
> >>>> 0x0000000000000001 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zcd extension for hart 
> >>>> 0x0000000000000001 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zca extension for hart 
> >>>> 0x0000000000000002 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zcd extension for hart 
> >>>> 0x0000000000000002 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zca extension for hart 
> >>>> 0x0000000000000003 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zcd extension for hart 
> >>>> 0x0000000000000003 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zca extension for hart 
> >>>> 0x0000000000000004 because privilege spec version does not match
> >>>> qemu-system-riscv64: warning: disabling zcd extension for hart 
> >>>> 0x0000000000000004 because privilege spec version does not match
> >>>
> >>> Why am I seeing these warnings? Does the mpfs machine type need to
> >>> disable some things? It only supports rv64imafdc per the DT, and
> >>> predates things like Zca existing, so emitting warnings does not seem
> >>> fair at all to me!
> >>
> >> QEMU will disable extensions that are newer than a priv spec version that 
> >> is set
> >> by the CPU. IIUC the icicle board is running a sifive_u54 CPU by default. 
> >> That
> >> CPU has a priv spec version 1_10_0. The CPU is also enabling C.
> >>
> >> We will enable zca if C is enabled. C and D enabled will also enable zcd. 
> >> But
> >> then the priv check will disabled both because zca and zcd have priv spec 
> >> 1_12_0.
> >>
> >> This is a side effect for a change that I did a few months ago. Back then 
> >> we
> >> weren't disabling stuff correctly.
> >
> > Yah, I did check out the blame, hence directing it at you. Thanks for
> > the explanation.
> >
> >> The warnings are annoying but are benign.
> >
> > To be honest, benign or not, this is kind of thing is only going to
> > lead to grief. Even though only the direct kernel boot works, we do
> > actually have some customers that are using the icicle target in QEMU.
> >
> >> And apparently the sifive_u54 CPU is being inconsistent for some time and
> >> we noticed just now.
> >> Now, if the icicle board is supposed to have zca and zcd then we have a 
> >> problem.
> >
> > I don't know, this depends on how you see things in QEMU. I would say
> > that it supports c, and not Zca/Zcf/Zcd, given it predates the
> > extensions. I have no interest in retrofitting my devicetree stuff with
> > them, for example.
> >
> >> We'll need to discuss whether we move sifive_u54 CPU priv spec to 1_12_0 
> >> (I'm not
> >> sure how this will affect other boards that uses this CPU) or remove this 
> >> priv spec
> >> disable code altogether from QEMU.
> >
> > I think you should stop warning for this? From my dumb-user perspective,
> > the warning only "scares" me into thinking something is wrong, when
> > there isn't. I can see a use case for the warning where someone tries to
> > enable Zca & Co. in their QEMU incantation for a CPU that does not
> > have the correct privilege level to support it, but I didn't try to set
> > any options at all in that way, so the warnings seem unfair?
>
>
> That's a fair criticism. We had similar discussions a few months back. It's 
> weird
> to send warnings when the user didn't set the extensions manually, but ATM we
> can't tell whether an extension was user enabled or not.
>
> So we can either show unfair warning messages or not show warnings and take 
> the risk
> of silently disabling extensions that users enabled in the command line. It 
> seems
> that the former is more annoying to deal with than the latter.
>
> I guess I can propose a patch to remove the warnings. We can send warning 
> again
> when we have a better solution.

A better solution is to just not enable Zca and friends automatically,
or at least look at the priv spec before we do

Alistair

>
>
> Daniel
>
>
> >
> > Cheers,
> > Conor.
>