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.

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

lscpu -C in linux can be used to display these cache structures.

Changes from v1:
	1) Replaced loop with memcpy
	2) Made virt_caches static in virt.c
	3) Added Daniel's RB tags

Sunil V L (4):

Sunil V L (4):
  tests/qtest/bios-tables-test: Allow PPTT for RISC-V
  hw/riscv/virt: Add ACPI PPTT table
  tests/qtest/bios-tables-test: Update riscv64 virt PPTT golden
    reference
  MAINTAINERS: Update Sunil's email id

 MAINTAINERS                       |   2 +-
 hw/riscv/virt-acpi-build.c        |   7 ++++
 hw/riscv/virt.c                   |  51 ++++++++++++++++++++++++++++++
 include/hw/riscv/virt.h           |   4 +++
 tests/data/acpi/riscv64/virt/PPTT | Bin 0 -> 96 bytes
 5 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 tests/data/acpi/riscv64/virt/PPTT

-- 
2.43.0

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.

I feel like you should describe why we want this somewhere in the
series

> 
> 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.

Alistair

> 
> lscpu -C in linux can be used to display these cache structures.
> 
> Changes from v1:
> 	1) Replaced loop with memcpy
> 	2) Made virt_caches static in virt.c
> 	3) Added Daniel's RB tags
> 
> Sunil V L (4):
> 
> Sunil V L (4):
>   tests/qtest/bios-tables-test: Allow PPTT for RISC-V
>   hw/riscv/virt: Add ACPI PPTT table
>   tests/qtest/bios-tables-test: Update riscv64 virt PPTT golden
>     reference
>   MAINTAINERS: Update Sunil's email id
> 
>  MAINTAINERS                       |   2 +-
>  hw/riscv/virt-acpi-build.c        |   7 ++++
>  hw/riscv/virt.c                   |  51
> ++++++++++++++++++++++++++++++
>  include/hw/riscv/virt.h           |   4 +++
>  tests/data/acpi/riscv64/virt/PPTT | Bin 0 -> 96 bytes
>  5 files changed, 63 insertions(+), 1 deletion(-)
>  create mode 100644 tests/data/acpi/riscv64/virt/PPTT

On Thu, Oct 15, 2026 at 12:19:53PM +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.

Thanks for picking up PPTT support. I can now rebase the RQSC support
[1] on this series.

However, RQSC actually needs PPTT revision 3, because it adds cache IDs
to the PPTT. The RQSC table references a capacity controller's cache by
the PPTT cache ID. In Linux, find_acpi_cache_level_from_id() and
acpi_pptt_get_cpumask_from_cache_id() return -ENOENT if PPTT rev < 3.

There is a new MPAM series by Jinjie Ruan which contains the patch
"[PATCH 04/37] hw/acpi: Build PPTT rev 3 with cache IDs for MPAM
cross-references" [2]. It bumps build_pptt() to revision 3 and gives
every cache node an ID.

I could just base the RQSC series on this PPTT series and that patch
03/37. But maybe there is a better way to coordinate adding PPTT v3?

Thanks,
Drew

[1] https://lore.kernel.org/all/20260202-riscv-rqsc-v1-0-dcf448a3ed73@kernel.org/
[2] https://lore.kernel.org/all/tencent_F9C68A515AC6C40BE2C32DB314E14CCB7106@qq.com/

Hi Drew!

On 10/20/2026 7:29 PM, Drew Fustini wrote:
> On Thu, Oct 15, 2026 at 12:19:53PM +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.
> 
> Thanks for picking up PPTT support. I can now rebase the RQSC support
> [1] on this series.
> 
> However, RQSC actually needs PPTT revision 3, because it adds cache IDs
> to the PPTT. The RQSC table references a capacity controller's cache by
> the PPTT cache ID. In Linux, find_acpi_cache_level_from_id() and
> acpi_pptt_get_cpumask_from_cache_id() return -ENOENT if PPTT rev < 3.
> 
> There is a new MPAM series by Jinjie Ruan which contains the patch
> "[PATCH 04/37] hw/acpi: Build PPTT rev 3 with cache IDs for MPAM
> cross-references" [2]. It bumps build_pptt() to revision 3 and gives
> every cache node an ID.
> 
> I could just base the RQSC series on this PPTT series and that patch
> 03/37. But maybe there is a better way to coordinate adding PPTT v3?

This PPTT support is acked and I believe we'll queue it in riscv-to-apply.next
shortly.

As for the PPTT rev3 patch in the "Add Arm MPAM emulation", my suggestion is
to put that on top of your series (i.e. your series will contain that patch).
That ARM series has 37 patches and might take awhile to go through, and your
work relies only on patch 04 ...  which happens to be an arch agnostic patch.
I believe it's fine for us to push it via the riscv queue.

I see that the author from the ARM series is CCed here.  Jinjie Ruan, are you
okay with us pushing your patch via the RISC-V tree?  It'll unblock Drew's work
and you'll have one less patch to worry about in your ARM MPAM work.


Thanks,
Daniel





> 
> Thanks,
> Drew
> 
> [1] https://lore.kernel.org/all/20260202-riscv-rqsc-v1-0-dcf448a3ed73@kernel.org/
> [2] https://lore.kernel.org/all/tencent_F9C68A515AC6C40BE2C32DB314E14CCB7106@qq.com/

在 2026/10/21 8:39, Daniel Henrique Barboza 写道:
> Hi Drew!
> 
> On 10/20/2026 7:29 PM, Drew Fustini wrote:
>> On Thu, Oct 15, 2026 at 12:19:53PM +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.
>>
>> Thanks for picking up PPTT support. I can now rebase the RQSC support
>> [1] on this series.
>>
>> However, RQSC actually needs PPTT revision 3, because it adds cache IDs
>> to the PPTT. The RQSC table references a capacity controller's cache by
>> the PPTT cache ID. In Linux, find_acpi_cache_level_from_id() and
>> acpi_pptt_get_cpumask_from_cache_id() return -ENOENT if PPTT rev < 3.
>>
>> There is a new MPAM series by Jinjie Ruan which contains the patch
>> "[PATCH 04/37] hw/acpi: Build PPTT rev 3 with cache IDs for MPAM
>> cross-references" [2]. It bumps build_pptt() to revision 3 and gives
>> every cache node an ID.
>>
>> I could just base the RQSC series on this PPTT series and that patch
>> 03/37. But maybe there is a better way to coordinate adding PPTT v3?
> 
> This PPTT support is acked and I believe we'll queue it in riscv-to-
> apply.next
> shortly.
> 
> As for the PPTT rev3 patch in the "Add Arm MPAM emulation", my
> suggestion is
> to put that on top of your series (i.e. your series will contain that
> patch).
> That ARM series has 37 patches and might take awhile to go through, and
> your
> work relies only on patch 04 ...  which happens to be an arch agnostic
> patch.
> I believe it's fine for us to push it via the riscv queue.
> 
> I see that the author from the ARM series is CCed here.  Jinjie Ruan,
> are you
> okay with us pushing your patch via the RISC-V tree?  It'll unblock
> Drew's work
> and you'll have one less patch to worry about in your ARM MPAM work.

Hi Daniel,

I'm fine to do so.

> 
> 
> Thanks,
> Daniel
> 
> 
> 
> 
> 
>>
>> Thanks,
>> Drew
>>
>> [1] https://lore.kernel.org/all/20260202-riscv-rqsc-v1-0-
>> dcf448a3ed73@kernel.org/
>> [2] https://lore.kernel.org/all/
>> tencent_F9C68A515AC6C40BE2C32DB314E14CCB7106@qq.com/
> 

-- 
Best regards,
Jinjie