On Sat, 2026-10-24 at 14:32 -0700, Drew Fustini wrote: > On Fri, Oct 23, 2026 at 05:28:31PM +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 alil, > > > > > > > > This series adds ACPI Processor Properties Topology Table > > > > (PPTT) > [..] > > > > 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? > > > > 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. > > RQSC is a RISC-V standard so I think it would be nice for the generic > cpu to have a set of caches defined. This would allow the ACPI virt
Lots of things are RISC-V standards, it doesn't mean it necessarily makes sense for every board. But there are no actual caches here, which is why it seems a bit strange Alistair > machine to produce a PPTT with cache IDs that RQSC can reference, and > it > would simplify testing for the RISC-V QoS support that I am trying to > upstream into Linux. > > Thanks, > Drew
