3 ms·

Ok, so maybe you do that in boot order or some boot motdes. But ... remove it? There is SO MUCH silicon these days, honestly I think CPUs should start putting

Ok, so maybe you do that in boot order or some boot motdes. But ... remove it? There is SO MUCH silicon these days, honestly I think CPUs should start putting instruction set compatibility cores in, so you still dedicate .5% to a 16 bit compatibility core, 1% to the 32 bit mode, and maybe even an ARM mode. Honestly, since all CPUs are basically fronted by microcode, why can't modern CPU microcode be compatible with multiple instruction sets? Or provide some sort of programmable microcode section so emulators aren't done in software? While I'm bitching, what happened to actually running multiple OSes at once? I have like 16 cores, gigabytes of RAM, multiple display outputs ... why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Intel (and AMD) are DESPERATE to figure out things to get people to use all their extra cores and silicon for. Well, how about making multiple OS on the same machine an actually pleasant experience? Hell, I would love to run a smartphone OS as well.

circuit10 3y ago
> why can't modern CPU microcode be compatible with multiple instruction sets? Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver
StillBored 3y ago
why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Sounds like what you want is a LPAR or proper type 1 hypervisor, which despite everyone claiming to be type 1 none of them really are. And this is largely caused by the various device HW standards on the PC not natively supporting virtualization (or like nvidia charging extra for SRIOV functionality on their GPUs). So what happens is that all these hypervisors need something like VirtIo or hypervisor emulation of devices (ex e1000/ne2000, sb16, etc) to provide generic storage/networking/display/input devices on top of devices which don't themselves provide any virtualization support. Which in PC land is pretty much everything that doesn't support SRIOV. Which in turn means that a heavyweight OS +driver stack is required to manage the HW. So, you could build a PC based LPAR hypervisor. It would just be limited to the SRIOV capable devices, or plugging in piles of adapters, each one uniquely bound to a single partition. Ex: https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf

circuit10 3y ago

> why can't modern CPU microcode be compatible with multiple instruction sets? Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver

StillBored 3y ago

why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Sounds like what you want is a LPAR or proper type 1 hypervisor, which despite everyone claiming to be type 1 none of them really are. And this is largely caused by the various device HW standards on the PC not natively supporting virtualization (or like nvidia charging extra for SRIOV functionality on their GPUs). So what happens is that all these hypervisors need something like VirtIo or hypervisor emulation of devices (ex e1000/ne2000, sb16, etc) to provide generic storage/networking/display/input devices on top of devices which don't themselves provide any virtualization support. Which in PC land is pretty much everything that doesn't support SRIOV. Which in turn means that a heavyweight OS +driver stack is required to manage the HW. So, you could build a PC based LPAR hypervisor. It would just be limited to the SRIOV capable devices, or plugging in piles of adapters, each one uniquely bound to a single partition. Ex: https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf