Thoughts on software-defined silicon [LWN.net]

Thoughts on software-defined silicon

Posted Feb 18, 2022 17:53 UTC (Fri) by jebba (guest, #4439)
Parent article: Thoughts on software-defined silicon

If Red Hat (or whoever) didn't add it to the Linux kernel, wouldn't it be much more difficult for Intel to do this? If so, then why add it?

to post comments

Thoughts on software-defined silicon

Posted Feb 18, 2022 18:29 UTC (Fri) by MatejLach (guest, #84942) [Link] (13 responses)

I agree with your sentiment but Intel has their own Linux engineers too.

Thoughts on software-defined silicon

Posted Feb 18, 2022 18:32 UTC (Fri) by jebba (guest, #4439) [Link] (12 responses)

Ya, I just mentioned Red Hat since they were in the link. Regardless of who writes it, the Linux developers can certainly reject it. They are under no obligation to add it. If they do, it seems it would do a lot to undercut Intel's attack.

Thoughts on software-defined silicon

Posted Feb 18, 2022 18:52 UTC (Fri) by tshow (subscriber, #6411) [Link] (11 responses)

I suspect what will kill this is AMD and ARM _not_ doing it, combined with users not bothering to rent whatever Intel is trying to hive off. This has the smell of something that is going to wind up in the tech news in a couple of years when Intel end-of-lifes it because it shows no prospect of paying for itself.

Thoughts on software-defined silicon

Posted Feb 18, 2022 19:24 UTC (Fri) by atnot (guest, #124910) [Link] (2 responses)

Indeed, Intel has already tried this once: https://en.wikipedia.org/wiki/Intel_Upgrade_Service

However, I think it's much more likely to work these days, especially in the enterprise space. Processors there are already highly segmented, with dozens of SKUs that only differ in what fuses are blown in them in the factory. In that sense, this can be a real benefit for enterprise customers, as they would presumably need to order and stock fewer CPU variants.

Of course the catch is that longer term, while there is an upper limit to the amount of segmented SKUs are feasible to produce, there is no such limit for feature toggles.

Thoughts on software-defined silicon

Posted Feb 23, 2022 22:57 UTC (Wed) by Trelane (guest, #56877) [Link] (1 responses)

> Processors there are already highly segmented, with dozens of SKUs that only differ in what fuses are blown in them in the factory.

The reason for this is because defects happen (semiconductor chip joke for free, right there). If you have a problem in a redundant part of you chip, you can close it off and sell the rest of the perfectly good chip at a lower price point. Or lower the clockspeed, whatever.

Interestingly, this is the opposite: it had _better_ have passed qual, but now it is walled off until the customer pays up.

> can be a real benefit for enterprise customers, as they would presumably need to order and stock fewer CPU variants.

On inventory: presumably this will need to be locked to the exact processor. (Or how else do you prevent copying the cert and enabling the functionality on _another_ chip? Maybe phone home? Contact a flex_lm install on your network?) So now you have to track the certs for your chip in _addition_ to the chip itself! Alternately, maybe it stays once enabled sweet, now you have to track the _variants_ of the same chip.

I don't see the upside honestly.

Thoughts on software-defined silicon

Posted Feb 23, 2022 23:52 UTC (Wed) by atnot (guest, #124910) [Link]

> The reason for this is because defects happen (semiconductor chip joke for free, right there). If you have a problem in a redundant part of you chip, you can close it off and sell the rest of the perfectly good chip at a lower price point. Or lower the clockspeed, whatever.

As I pointed out elsewhere, the degree to which this happens is greatly overstated by semiconductor companies. True, not every chip is going to reach the full clock speed and have all cores working. But for one, especially on mature nodes, the majority of them do and also that doesn't apply for many other lines they already segment along like maximum memory capacity, ECC, software features like Ryzen PRO/vPro etc. The far majority of chips are cut down because they wouldn't sell at a higher price, not because they are defective in any meaningful way. They do this because relatively speaking, the individual chips are dirt cheap (tens of dollars), all of the cost is in the NRE.

> So now you have to track the certs for your chip in _addition_ to the chip itself! Alternately, maybe it stays once enabled sweet, now you have to track the _variants_ of the same chip.

It is generally rare for a cpu to leave a system after it gets put in and tracking per-device licenses already needs to be done for all of the other hardware like switches, BMCs, etc. so it's not really a lot of extra effort for them.

Thoughts on software-defined silicon

Posted Feb 18, 2022 19:35 UTC (Fri) by developer122 (guest, #152928) [Link] (5 responses)

I already avoid intel chips because they paywall ECC.

My NAS runs on one of the cheapest (and most power efficient) CPUs AMD ever made, but it's fully stacked with ECC RAM for my ZFS ARC.

AMD efficient ECC

Posted Feb 19, 2022 9:20 UTC (Sat) by sdalley (subscriber, #18550) [Link] (2 responses)

That sounds really interesting. Any details on which processor/mainboard you used?

AMD efficient ECC

Posted Mar 2, 2022 18:50 UTC (Wed) by anton (subscriber, #25547) [Link] (1 responses)

Asus and Asrock mainboards, and some Gigabyte ones support ECC on AM4 boards. AFAIK all CPUs are good except the non-Pro APUs. We have a Ryzen 1600X, 1800X, several 3900X, and a 5800X all working with ECC.

AMD efficient ECC

Posted Mar 2, 2022 20:39 UTC (Wed) by sdalley (subscriber, #18550) [Link]

Thanks for this. I've just seen the Gigabyte B550I Aorus Pro which does ECC and is miniITX too. Would make a nice low-dissipation system with a Ryzen 5650GE Pro APU.

But, my, how prices for this kind of stuff have shot up over the last few years...

Thoughts on software-defined silicon

Posted Feb 22, 2022 17:48 UTC (Tue) by IgorTorrente (guest, #156538) [Link] (1 responses)

Complementing the sdalley question.

Which ECC Ram kit are you using?

Thoughts on software-defined silicon

Posted Mar 2, 2022 18:53 UTC (Wed) by anton (subscriber, #25547) [Link]

We use whatever is available at a good price. In our 5800X box we use 4 Kingston KSM32ED8/32ME.

Thoughts on software-defined silicon

Posted Feb 19, 2022 3:35 UTC (Sat) by k8to (guest, #15413) [Link]

Maybe? I'd more expect amd and some arm vendors to do the same.

Thoughts on software-defined silicon

Posted Feb 19, 2022 10:16 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

The optimist in me thinks that this might be targeted only to cloud vendors, who rent a subset of a machine at a time and also might rent the same machine for slightly different instance types. Many instruction set extensions can be hidden from CPUID but would still be present in the processor. Different instance types then could use SDSi to have a different set of features enabled for real, and not just in CPUID.

The pessimist in me thinks that this is just wishful thinking, though.

Thoughts on software-defined silicon

Posted Feb 19, 2022 13:37 UTC (Sat) by nim-nim (subscriber, #34454) [Link] (2 responses)

No chance of Red Hat refusing to do it now they belong to IBM, who already practices this.

And even if everyone in the community refused to add it Intel would just add the patch to its own kernel and require use of this kernel. Like Nvidia does for its own hardware.

Free software means adding antifeatures to a fork is cheap (especially if they are self-contained).

Thoughts on software-defined silicon

Posted Feb 19, 2022 22:52 UTC (Sat) by jebba (guest, #4439) [Link] (1 responses)

But then they'd be left having to maintain their own fork for that CPU series. There's a lot of overhead there.

Thoughts on software-defined silicon

Posted Feb 24, 2022 10:39 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Not really, for something that only needs minimal interaction with the rest of the kernel. Which should be the case for something that just loads a key.