Re: [PATCH 00/37] Add Arm MPAM emulation

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/10/16 18:20, Peter Maydell 写道:
> On Fri, 16 Oct 2026 at 10:47, Jinjie Ruan <2118537295@qq.com> wrote:
>>
>> From: Jinjie Ruan <ruanjinjie@huawei.com>
>>
>> MPAM (Memory System Resource Partitioning and Monitoring) is Arm's
>> architecture for partitioning and monitoring system memory resources
>> - Cache portions
>> - Capacity limits
>> - Memory bandwidth and priority
>>
>> And MPAM is the Arm counterpart of x86 RDT, which Linux exposes to user
>> space via resctrl.
>>
>> QEMU so far has no MPAM support at all: the CPU-side system registers
>> are missing (a guest kernel that probes FEAT_MPAM takes an UNDEFINED
>> exception), and there are no Memory System Components (MSCs), so a virt
>> guest cannot exercise resctrl on Arm.
>>
>> This series adds MPAM 1.1 emulation for the virt machine,
>> and the structure is as below:
> 
>> With this, a Linux guest booted with -M virt,mpam=on (plus NUMA nodes)
>> mounts resctrl with the full schemata set (L2/L3 CAT, capacity, MBA,
>> priority), and MBM bandwidth and L2/L3 occupancy counters track the
>> configured controls.
> 
> I guess my question here is "how much is this actually doing,
> and how much is it 'we provide enough software-facing interface
> to keep the guest happy'" ? My (rather shallow) understanding of
> MPAM is that it's essentially adding tags to memory transactions
> and then accounting how much bandwidth each tag is using. That
> seems obviously infeasible for emulation, but on the other hand

Hi Peter,

Yes, I agree with you.

Implementing MPAM bandwidth control and partitioning at the
performance-effect level in QEMU is neither feasible nor necessary, and
it is not in line with QEMU’s original purpose as a fast functional
emulator.

We only need to implement the functionality-related parts (i.e., the
register interfaces and control flow) to ensure that the software stack
can correctly recognize and configure MPAM, without simulating the real
performance impact produced by those configurations.

> this looks like it's rather larger than a minimal "we provide
> the register interface but it does nothing", so what are we doing?

By implementing MPAM-related register interfaces and control flow, as
well as the MSC hardware topology in QEMU, we can understand the resctrl
framework and interfaces in Linux, along with the related hardware
topology discovery process. This facilitates kernel debugging and
pre-silicon testing, and also allows us to debug and test test cases,
avoiding the complexity and slowness of testing on FPGA.

Through this series of QEMU implementations, I discovered many kernel
issues and test-case issues in advance before FPGA testing, accelerating
the development and testing of new kernel features (such as narrow PARTID).

Moreover, as far as I understand, many hardware vendors have not yet
implemented MPAM. Implementing it in QEMU helps enable MPAM on Linux,
and then understand, learn, test, and even develop some MPAM-related
features.

Link:
https://lore.kernel.org/all/20261012082337.822258-1-ruanjinjie@huawei.com/

> 
> thanks
> -- PMM

-- 
Best regards,
Jinjie