[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <549411914.201492.1765950408211@app.mailbox.org>
Date: Tue, 16 Dec 2025 21:46:48 -0800 (PST)
From: vdso@...lbox.org
To: Anirudh Rayabharam <anirudh@...rudhrb.com>
Cc: kys@...rosoft.com, decui@...rosoft.com, haiyangz@...rosoft.com,
linux-kernel@...r.kernel.org, longli@...rosoft.com,
wei.liu@...nel.org, linux-hyperv@...r.kernel.org
Subject: Re: [PATCH 1/3] hyperv: add definitions for arm64 gpa intercepts
> On 12/16/2025 9:08 PM Anirudh Rayabharam <anirudh@...rudhrb.com> wrote:
>
>
> On Tue, Dec 16, 2025 at 07:07:45AM -0800, vdso@...lbox.org wrote:
> >
> > > On 12/16/2025 6:20 AM Anirudh Rayabharam <anirudh@...rudhrb.com> wrote:
> >
> > [...]
> >
> > > +#if IS_ENABLED(CONFIG_ARM64)
> > > +union hv_arm64_vp_execution_state {
> > > + u16 as_uint16;
> > > + struct {
> > > + u16 cpl:2;
> >
> > That looks oddly x86(-64)-specific (Current Priviledge Level).
> >
> > Unless I'm mistaken, CPL doesn't belong here, and the bitfield isn't
> > used on ARM64. Provided the layout of the struct is correct, the
> > bitfield can have a better name of `reserved0` or something like that.
>
> Hmmm... this is how it is defined in the hypervisor headers though.
The questions would be why the hypervisor has got that there (e.g., the
definitions of that struct for x86 and ARM64 are merged), and if Linux needs
to care about the reason valid in the hv's codebase. Perhaps the definitions
are merged there to write less arch-specific code, similar to what Stas suggested
for the patch 2.
I haven't been able to find anything called CPL in the ARM64 arch docs, and
that field really sticks out as the x86-64's CPL. Naming it like that in an
ARM64-specific structure doesn't look justified.
Powered by blists - more mailing lists