This article is more than 1 year old

Intel teases 'software-defined silicon' with Linux kernel contribution – and won't say why

It might enable activation of entirely new features on existing Xeon CPUs … or, you know, not

Intel has teased a new tech it calls "Software Defined Silicon" (SDSi) but is saying almost nothing about it – and has told The Register it could amount to nothing.

SDSi popped up around three weeks ago in a post to the Linux Kernel mailing list, in which an Intel Linux software engineer named David Box described it as "a post-manufacturing mechanism for activating additional silicon features".

"Features are enabled through a license activation process," he wrote. "The SDSi driver provides a per-socket, ioctl interface for applications to perform three main provisioning functions." Those provisioning functions are:

  1. Provision an Authentication Key Certificate (AKC) – a key written to internal NVRAM that is used to authenticate a capability-specific activation payload.
  2. Provision a Capability Activation Payload (CAP) – a token authenticated using the AKC and applied to the CPU configuration to activate a new feature.
  3. Read the SDSi State Certificate – containing the CPU configuration state.

Box's post also pointed to a GitHub page that includes the following explanation:

Intel Xeon family processors with support for Intel Software Defined Silicon (SDSi) allow the configuration of additional CPU features through a license activation process.

Between that GitHub mention and the three functions added to the Linux kernel, it seems plain that Intel could ship Xeons with latent features you could enable by sending it some cash.

Intel's offered precious few other details. The GitHub page includes a document detailing how to use SDSi-equipped silicon to enable dormant features, but with no detail on what new features could be activated with this tech.

The Register asked Intel to explain its Linux Kernel mailing list post. Chipzilla offered us the following non-committal response:

We’re not going into a lot of details about Software Defined Silicon at this time. As you know, Intel regularly submits code to the Linux Kernel that could be used in future products. And that’s what happened in this case. If we plan to implement these updates in future products we will provide a deeper explanation of how they are implemented at that time.

Yeah, right. Intel has gone to all the trouble of cooking up a way to license highly configurable Xeons, but hasn't decided if it will become a product, and tossed the tech into the Linux kernel anyway.

If you believe that, The Register has a bridge we'd like to sell you.

So let's ponder what Intel could be up to here – starting with why Intel wants to license CPU features.

Today, Intel sells a CPU and as often as not doesn't see any more cash from its customers until their next purchase – which could be years into the future. Licensing CPU features would potentially give Intel more revenue, more often, perhaps even letting it create the kind of subscription services that investors adore because they boost revenue – and make its arrival more predictable.

Intel is going to need predictable cashflow to fund its plans to spend tens of billions on new factories.

Those factories are infamously complex, and Intel works them hard – partly because it makes many variants of its products. If Intel could make fewer variants, and instead pack all its tech into a smaller number of SKUs that could be re-configured in software, production savings could be substantial. Customers would still pay a premium for high-end kit, which would be switched on by software rather than created as discrete products.

We also know that Intel plans to make its products yet more complex, with the "Alder Lake" architecture that mixes and matches cores of different kinds on the same die.

Configurable CPUs could delight customers, by letting them buy a CPU with advanced capabilities like Intel's AVX-512 extensions – a tech aimed at speeding machine learning – but pay to use those extensions only when needed, rather than wearing an up-front cost. Or buyers could acquire servers knowing they have some extra overhead to turn on as their needs increase.

That kind of flexibility is not far-fetched. In fact, Intel already offers something similar in its Speed Select Technology (SST) – an offering that allows users to set CPUs into configurations matched to different workloads. SST also allows definition of virtual CPUs with characteristics that differ from the physical CPU.

Another current option emphasising composability and flexibility comes from HPE, which offers silicon-on-demand that allows customers of its GreenLake ITaaS environment to vary the numbers of cores that are active on Intel-powered servers and pay only for those cores, rather than having to rent a whole server.

Remember, too, the mid-2010s fad for composable infrastructure – the notion that a collection of connected components could be assembled into servers that meet the requirements of the day. That sort of concept nearly always takes a few years to go from nifty idea to practical adoption.

Intel ended its response to The Register's questions about SDSi by stating: "We're continuously innovating to ensure we enable flexible solutions to meet the unique demands of our customers and partners and lead the industry in product capabilities and features."

Which means absolutely nothing. Yet going to all the trouble of inserting SDSi in the Linux kernel surely signals something substantial is brewing. And if that something is configurable and/or composable CPUs, Intel may have something rather more substantial to say. ®

More about

More about

More about


Send us news

Other stories you might like