Hi Marc,
在 2023/7/13 星期四 17:40, Marc Zyngier 写道:
On Thu, 13 Jul 2023 10:10:01 +0100,
"chenxiang (M)" <chenxiang66@xxxxxxxxxxxxx> wrote:
Hi Marc,
在 2023/7/13 星期四 14:56, Marc Zyngier 写道:
On Thu, 13 Jul 2023 03:35:39 +0100,
"chenxiang (M)" <chenxiang66@xxxxxxxxxxxxx> wrote:
Hi Marc,
在 2023/7/12 星期三 16:36, Marc Zyngier 写道:
On Wed, 12 Jul 2023 08:55:05 +0100,
chenxiang <chenxiang66@xxxxxxxxxxxxx> wrote:
From: Xiang Chen <chenxiang66@xxxxxxxxxxxxx>
For those PMU system registers defined in sys_reg_descs[], use macro
PMU_SYS_REG() / PMU_PMEVCNTR_EL0 / PMU_PMEVTYPER_EL0 to define them, and
later two macros call macro PMU_SYS_REG() actually.
Currently the input parameter of PMU_SYS_REG() is other macro which is
calculation formula of the value of system registers, so for example, if
we want to "SYS_PMINTENSET_EL1" as the name of sys register, actually
the name will be as following:
(((3) << 19) | ((0) << 16) | ((9) << 12) | ((14) << 8) | ((1) << 5))
To fix the issue, use the name as a input parameter of PMU_SYS_REG like
MTE_REG or EL2_REG.
Why is the name relevant? Is this related to tracing?
I think It is not related to tracing. I find the issue when i want to
know which system reigsters are set
when on live migration and printk the name of sys_reg_desc in function
kvm_sys_reg_set_user,
find the name of some registers are abnormal as followings:
[ 227.145540] kvm_sys_reg_set_user 3427:SYS_FAR_EL1
[ 227.158057] kvm_sys_reg_set_user 3427:SYS_PAR_EL1
[ 227.170574] kvm_sys_reg_set_user 3427:(((3) << 19) | ((0) << 16) |
((9) << 12) | ((14) << 8) | ((1) << 5))
[ 227.188037] kvm_sys_reg_set_user 3427:(((3) << 19) | ((0) << 16) |
((9) << 12) | ((14) << 8) | ((2) << 5))
[ 227.205511] kvm_sys_reg_set_user 3427:SYS_MAIR_EL1
[ 227.218117] kvm_sys_reg_set_user 3427:SYS_PIRE0_EL1
So what is this if not some form of tracing?
Ah, i was misunderstood your question. I thought you aksed whether
it is related to kernel tracing (which is already existed in kernel)
such as tracepoint or debugfs.
But that's my point: tracepoints such as kvm_sys_access already output
the name (as well as the encoding), and are likely to be affected by
this problem.
And that's a much more interesting justification for this change.
Got it. Thanks.
Thanks,
M.
