Message-ID:
 <CH8PR21MB52221DBBF4D87FC24013FACFCA87A@CH8PR21MB5222.namprd21.prod.outlook.com>
Date: Tue, 6 Jan 2026 00:10:46 +0000
From: Jon Lange <jlange@...rosoft.com>
To: "dan.j.williams@...el.com" <dan.j.williams@...el.com>, Dave Hansen
	<dave.hansen@...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: [EXTERNAL] Re: "Paravisor" Feature Enumeration

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?  Any advantage that doesn't have an equivalent on Arm just seems like it would perpetuate the cross-architecture problem and would lead right back to some other proposal that works on multiple architectures, so I'm very curious to understand how CPUID provides a meaningful advantage that doesn't invite new problems.

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?

-Jon

-----Original Message-----
From: dan.j.williams@...el.com <dan.j.williams@...el.com> 
Sent: Monday, January 5, 2026 4:02 PM
To: Dave Hansen <dave.hansen@...el.com>; Jon Lange <jlange@...rosoft.com>
Cc: Williams, Dan J <dan.j.williams@...el.com>; 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; 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: [EXTERNAL] Re: "Paravisor" Feature Enumeration

[You don't often get email from dan.j.williams@...el.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Dave Hansen wrote:
> First,
>
> Jon and John gave a talk in Tokyo about feature enumeration under
> paravisors:
>
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flp
> > c.events%2Fevent%2F19%2Fcontributions%2F2188%2Fattachments%2F1896%2F
> > 4057%2F05-Paravisor-Integration-with-Confidential-Services.pdf&data=
> > 05%7C02%7Cjlange%40microsoft.com%7C2dfafa359d6b4bc7488308de4cb6e7ed%
> > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639032545637571280%7CUn
> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JKT2
> > 2S031BpC1gwBHMFOOHfA%2Fx91vXaysS6Gg2kMVeE%3D&reserved=0
>
> The tl;dr for me at least was that they'd like a common and consistent 
> means of enumerating these features in OSes, regardless of the
> environment: TDX, SEV-SNP or even ARM CCA.
>
> I wanted to explore one corner of the solution space a bit. There was 
> a pretty limited audience of folks in the room. Please feel free to 
> flesh out the cc list with anyone I missed.
>
> Dan Williams' first thought seemed to revolve around having some kind 
> of platform-independent device that could do the enumeration. Maybe a 
> synthetic PCI device. I'm sure Dan can chime in to fill in the details 
> that I missed.

More that it sounded like "just another firmware enumeration" problem, where a platform device is one of the results along with related firmware tables and objects.

> I immediately just thought of CPUID. We already have a whole region of 
> CPUID (0x40000000) that hypervisors use to enumerate stuff to guests 
> by convention. It wouldn't be a large leap at all to carve out a chunk 
> of that so that paravisors can use it.
>
> But the biggest barrier I see there is that our ARM friends don't have 
> CPUID. It seems like they _mostly_ have bit-by-bit aliases in ACPI or 
> DeviceTree for the x86 CPUID bits, like:
>
>       X86_FEATURE_KVM_CLOCKSOURCE in arm,pvclock or
>       X86_FEATURE_KVM_STEAL_TIME  in arm,kvm-steal-time
>
> As far as I can tell, these aliases are all done ad-hoc. This approach 
> could obviously be extended to paravisor features, but it would 
> probably be on the slow side to do it for each new feature.

"Slow" as in standardization time?

> It _seems_ like we could pick a chunk of CPUID space (say 32-bits of 
> it) and alias it 1:1 with some DeviceTree/ACPI property, say 
> "arm,paravisor-features". Kernel code would just be written to say 
> "check feature 13" and the arch-specific helpers would either steer 
> that to CPUID or DeviceTree.
>
> Is there anything like that today that's cross-architecture and 
> cross-hypervisor?

That seems the definition of an ACPI description.

> Is there anything stopping us from carving out a chunk of CPUID for 
> this purpose?

At what point does an ACPI property become a CPUID? In other words if there is an ACPI / DeviceTree enumeration of CPU/platform capabilities in firmware that can supsersede / extend native enumeration, does it matter if x86 maps that to extended CPUID space and ARM maps it however is convenient?

I have no problem with an extended CPUID concept, just trying to understand more about the assumptions.

Powered by blists - more mailing lists