On Fri, Jul 14, 2023 at 11:14 AM Daniel Henrique Barboza <dbarb...@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. >
