On Mon, Oct 26, 2026 at 11:56:38PM +0000, Alistair Francis wrote: > 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: [..] > > > 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 :)
I could add caches for the Ascalon core complex in Atlantis but the topology is pretty simple with just private L1 and shared L2. The tt-atlantis machine is also device tree only, so it would not produce a PPTT or RQSC table. A generic cpu with L1, L2 and L3 caches like Sunil defined is ideal for testing my Qemu RQSC series [1], since RQSC needs to reference cache IDs from PPTT. My plan is to rebase my RQSC series once PPTT support lands and send the new revision as a non-RFC series since RQSC has been ratified. Qemu is important for testing the RISC-V QoS support in Linux [2], because I'm not aware of any hardware yet that supports all 4 features of CBQRI: capacity allocation, capacity monitoring, bandwidth allocation, and bandwidth monitoring. Ascalon only supports capacity allocation, and I have not seen public details from other vendors about which CBQRI features have been implemented. Thanks, Drew [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/
