On Fri, 2026-10-23 at 17:28 +0530, Sunil V L wrote: > On Thu, Oct 22, 2026 at 10:23 AM Alistair Francis > <[email protected]> wrote: > > > > On Thu, 2026-10-15 at 12:19 +0530, Sunil V L wrote: > > > Hi all, > > > > > > This series adds ACPI Processor Properties Topology Table (PPTT) > > > support to > > > the RISC-V virt machine. PPTT allows the guest to discover the > > > processor and > > > cache topology exposed by the machine, which is useful for making > > > better > > > scheduling and cache-management decisions. > > > > > > The implementation describes the RISC-V virt cache hierarchy with > > > separate > > > L1 instruction and data caches, followed by unified L2 and L3 > > > caches. > > > It also > > > enables the corresponding cache and cluster properties in the > > > machine > > > SMP > > > description and wires the generated PPTT into the existing ACPI > > > table > > > build. > > > > > > Unlike ARM, RISC-V doesn't have a way to discover the Cache > > > topology from registers. Hence, I am hardcoding default values > > > for > > > the > > > cache topology structures. These cache topology structures are > > > added > > > in > > > virt.c itself so that a future series can add support for DT as > > > well. > > > In > > > future, it can be enhanced to support vendor cpu/soc specific > > > cache > > > information to override this default hardcoded cache details. > > > > Why not add a vendor cpu/soc specific one to a vendor board? That > > way > > it actually model hardware instead of just providing the guest some > > made up information. > > > Thanks for the feedback! > > Just to make sure I understand your suggestion correctly: should we > avoid > defining a hardcoded cache topology for the generic CPU on virt, and > generate > PPTT cache information only for CPU models that provide an > appropriate cache > hierarchy?
It was a question Something to keep in mind is that I (and others on the list) don't know all of the context that you know about this extension. So the cover letter and commit messages should describe **why** we want this. Remember, I'm (and other on the list) are not part of RVI. We don't have the insight that you have. I also don't know what Drew is working on (I see some patches today, but before then I didn't know). So, when sending patches please try to explain why we want them. The question was, what use/value is there in faking some cache layout that doesn't exist? There might be a good reason, but that should be justified and explained. > > I can certainly omit the cache information for the generic CPU. The > consequence > is that Drew's CBQRI series, which requires cache information, would > need a > suitable CPU model before it can be used with virt. Drew, please > share > your thoughts. Drew works at a company making it's own CPU, I would argue he can just use that :) Alistair > > > I feel like you should describe why we want this somewhere in the > > series > > > Sure. Let me update the cover letter why PPTT support is required. > > > > > > > The series also updates the bios-tables-test data and removes the > > > temporary > > > PPTT entry from the allowed-diff list. The generated table is 96 > > > bytes and > > > describes the package, cluster, and processor hierarchy for the > > > virt > > > machine. > > > > > > This work follows the discussion and earlier work shared here: > > > https://lists.gnu.org/archive/html/qemu-riscv/2024-01/msg00928.html > > > > > > I have retained the contribution from Sia Jee Heng and added his > > > Signed-off-by tag to the relevant patch. > > > > > > To enable cache structures in the PPTT, one should use similar to > > > below > > > command line option. > > > > > > -M virt,smp-cache.0.cache=l1d,smp-cache.0.topology=core,smp- > > > cache.1.cache=l1i,smp-cache.1.topology=core,smp- > > > cache.2.cache=l2,smp- > > > cache.2.topology=cluster,smp-cache.3.cache=l3,smp- > > > cache.3.topology=socket > > > > Obviously :P > > > > Let's at least add this to the virt machine docs so it's useful for > > someone. > > > Sure. > > Thanks, > Sunil
