linux-kernel - Re: "Paravisor" Feature Enumeration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4c8524e5-b3e1-4113-a4e3-d3615465d9a8@intel.com>
Date: Mon, 5 Jan 2026 16:46:34 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Jon Lange <jlange@...rosoft.com>,
 "dan.j.williams@...el.com" <dan.j.williams@...el.com>
Cc: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>, John Starks
 <John.Starks@...rosoft.com>, Will Deacon <will@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
 LKML <linux-kernel@...r.kernel.org>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: "Paravisor" Feature Enumeration

On 1/5/26 16:10, Jon Lange wrote:
> It's not clear to me what advantages are gained by reflecting ACPI
> information into CPUID.  ACPI is already available and is usable
> across architectures, unlike CPUID.  What advantage is gained by
> replicating the information into CPUID?

If there is an ACPI approach that is expressive and agile enough to
convey the necessary information, then there's zero reason to replicate
it anywhere, CPUID included.

Like I said in the mail to Dan, I _think_ the current state of the art
for host=>guest enumeration involves ACPI wrapping DeviceTree properties
on ARM which mirror x86 CPUID bits.

> In the LPC session that Dave cites, Dan (I think it was Dan) threw
> out another suggestion: have the hypervisor driver detect the
> paravisor configuration using whatever is appropriate for that
> hypervisor architecture.  I find this to be a very attractive
> direction because it eliminates the need to define standards that
> can be supported across hypervisors (and across virtual firmware
> implementations), and reduces it just to a small set of concepts
> that can be fed into the kernel.  This could keep the enumeration
> out of the hands of ACPI altogether - thus no slow standards
> development.  Are there downsides to this approach that make it
> unattractive?
I think you're saying that we'd have a fixed set of Linux-defined
features. Hypervisor drivers would set the features up. Generic,
architecture and vendor-neutral code would consume the feature enumeration.

That sounds familiar and sane to me. It's generally what we have with
the Linux-defined X86_FEATURE_* bits. Linux defines their behavior and
consumes them in generic code. x86 vendor-specific code sets them.