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