public inbox for linux-hyperv@vger.kernel.org
 help / color / mirror / Atom feed
From: mrathor <mrathor@linux.microsoft.com>
To: Anirudh Rayabharam <anirudh@anirudhrb.com>, vdso@mailbox.org
Cc: "kys@microsoft.com" <kys@microsoft.com>,
	"haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>,
	"decui@microsoft.com" <decui@microsoft.com>,
	"longli@microsoft.com" <longli@microsoft.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts
Date: Mon, 5 Jan 2026 11:44:29 -0800	[thread overview]
Message-ID: <f2bb047e-8b85-b37a-9418-ab5ed8728ac9@linux.microsoft.com> (raw)
In-Reply-To: <atnnav7x4gzbeghpuh4fjpdig3i4zxzb56kpfvx3stgelajbm6@52lzmsycwzss>

On 1/5/26 11:27, Anirudh Rayabharam wrote:
> On Mon, Jan 05, 2026 at 08:06:02AM -0800, vdso@mailbox.org wrote:
>>
>>> On 01/05/2026 4:28 AM  Anirudh Rayabharam <anirudh@anirudhrb.com> 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


  reply	other threads:[~2026-01-05 19:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-05 12:28 [PATCH v2 0/2] Fixes for movable pages Anirudh Rayabharam
2026-01-05 12:28 ` [PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts Anirudh Rayabharam
2026-01-05 16:06   ` vdso
2026-01-05 19:27     ` Anirudh Rayabharam
2026-01-05 19:44       ` mrathor [this message]
2026-01-05 17:01   ` Stanislav Kinsburskii
2026-01-05 12:28 ` [PATCH v2 2/2] mshv: handle gpa intercepts for arm64 Anirudh Rayabharam
2026-01-05 17:04   ` Stanislav Kinsburskii
2026-01-06  7:21     ` Anirudh Rayabharam
2026-01-06 16:36       ` Stanislav Kinsburskii
2026-01-06 18:59         ` Nuno Das Neves
2026-01-07  7:35         ` Anirudh Rayabharam
2026-01-15  7:31 ` [PATCH v2 0/2] Fixes for movable pages Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2bb047e-8b85-b37a-9418-ab5ed8728ac9@linux.microsoft.com \
    --to=mrathor@linux.microsoft.com \
    --cc=anirudh@anirudhrb.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longli@microsoft.com \
    --cc=vdso@mailbox.org \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox