Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

older platforms and software was really bad at dealing with virtualisation

As far as I know, it just enables a few new CPU instructions, but older software that didn't know about them wouldn't use them anyway?



It's not using vs. not-using, but software compiled at a time where the Vt-x and Vt-d quirks were not known causing all sorts of crashes and intermittent freezes.

So for 'broken' software (and there was a lot of it - even back in the day of the turbo button) it often can be better to just not allow the software to see/use all the hardware.

Example of the weird stuff you have to first know about, then detect and then mitigate, on a per-device basis: https://marc.info/?l=linux-iommu&m=139305749014927&w=2 and that's something that when you don't do it, the software doesn't deal with it very well. Since not all software can be influenced by its operator (be it lack of skill, resources or simply legally not allowed), it can be much easier to just have a switch in the firmware where you can hide it from the software.

Switching code paths based on MSR is something that is one of the safest (and broadest) things you can do early on when you start up, so in a way, such a switch is merely "supplying configuration" but in a pre-boot fashion.


That example seems to be about IOMMU, which is also something that software needs to know about in order to use. I guess you were actually referring to features which the software knows about, but have errata?

As another datapoint, I have a machine with VT-x enabled and Windows 98 runs fine. It just doesn't know about the extra features the CPU has (like it also doesn't know about it having more than one core).


Yeah, there is a divide between what software will or will not crash. Essentially it's a combination of software using features and the features not being stable.

The best combination is either software that knows the issues for each implementation and can work with it, or software that doesn't use the features (either not using them natively or by making it unavailable to the software).

It's amazing how string-and-chewing-gum some hardware is with software working around so many issues to not crash. Sometimes there is good documentation, errata or usable flags (like MSR bits), sometimes it's just 'lower the pressure until it stops crashing' and you get a fat list of quirks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: