qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH fo


From: Conor Dooley
Subject: 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)
Date: Thu, 13 Jul 2023 23:47:33 +0100

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?

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]