On 1/5/26 11:27, Anirudh Rayabharam wrote:
On Mon, Jan 05, 2026 at 08:06:02AM -0800, [email protected] wrote:
On 01/05/2026 4:28 AM Anirudh Rayabharam <[email protected]> wrote:
[...]
+#if IS_ENABLED(CONFIG_ARM64)
+union hv_arm64_vp_execution_state {
+ u16 as_uint16;
+ struct {
+ u16 cpl:2; /* Exception Level (EL) */
Anirudh,
Appreciate following up on the CPL field in that ARM64 structure
and adding the comment!
My bad, actually I was gonna explain this in a reply to the previous
thread but it slipped my mind.
Still, using something from the x86 parlance (CPL) and adding a comment
stating that this is actually ARM64 EL certainly needs an explanation
as to _why_ using an x86 term here is beneficial, why not just call
the field "el"? As an analogy, here is a thought experiment of writing
#ffdef CONFIG_ARM64
u64 rax; /* This is X0 */
#endif
where an x86 register name would be used to refer to X0 on ARM64, and
that doen't look natural.
Well, in this case neither CPL nor EL is an architecturally defined
register name. These are just architectural concepts.
So far, I can't seem to find drawbacks in naming this field "el", only
benefits:
* ARM64 folks will immediately know what this field is, and
* the comment isn't required to explain the situation to the reader.
Do you foresee any drawbacks of calling the field "el" and dropping
the comment? If you do, would these drawbacks outweigh the benefits?
As a general rule we want to keep these headers exactly same as the
hypervisor headers so that we can directly ingest them at some point in
the future.
Having said that, we've communicated the concern to the hyp team, and
there is no opposition to changing it. After the change is made on
that side, it will propagate to this side in future.
Thanks for your diligence.
-Mukesh
I am not seeing a substantial benefit in breaking that rule. The CPL ->
EL analogy is not a huge leap to make IMO and the comment helps. One
could think of "current privilege level" as a generic term here.
Thanks,
Anirudh.
[...]
--
Cheers,
Roman
