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)

[Daniel Henrique Barboza]

On 7/14/23 00:12, Alistair Francis wrote:
> 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

Good idea. In fact we should do that for all extensions that we're enabling
automatically.


I'll work something out. Thanks,


Daniel

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