What kind of issues you expect this selftest to find?Current vLBR event break the generic perf schedule rule. So I write the fix commits and selftest to avoid future broken again.
IMO, it verifies the generic perf schedule rules but cannot find specific issues.
e.g., whether the LBR data is corrupted in some cases. If the selftest can verifyOnce vLBR event is preempted, I see designing gap and guest should get wrong data, it is out of this commits scope to fix the gap and to verify the result.
whether
guest/host data is maintained correctly in a high contention env., that can be
better to
sever the purpose of selftest.
I should add this into commit message.
[...]
thanks
On 6/16/2023 7:33 PM, Xiong Zhang wrote:
When guest access LBR msr at the first time, kvm will create a vLBR
event, vLBR event joins perf scheduler and occupy physical LBR for guest usage.
Once vLBR event is active and own LBR, guest could access LBR msr.
But vLBR event is per process pinned event, perf has higher priority event:
per cpu pinned LBR event, perf has lower priority events also: per cpu
LBR event and per process LBR event.
So if host doesn't have higher priority per cpu pinned LBR event, vLBR
event could occupy physical LBR always. But once per cpu pinned LBR
event is active, vLBR event couldn't be active anymore, then guest
couldn't access LBR msr.
This commit adds test case to cover guest and host lbr contend.
Signed-off-by: Xiong Zhang <xiong.y.zhang@xxxxxxxxx>
---
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/ucall_common.h | 17 ++