Theory - VM's in BIOS

This idea is just a thought I had, and maybe there is something there already but here it goes..

As the title suggests, have Virtual Machines build into the BIOS, and not boot the traditional one operating system per machine, but have the ability to have multiple. But it would not be like a normal VMware Vm, but rather in the BIOS it would have options to setup each user (they can run whatever OS, simultaneously) and in the BIOS you would select what inputs each OS gets to "use." -So you could say use monitor comm 1 for user 1, and usb comm 1, 3, 7 for user 1, etc...

It is just an idea and obviously may be completely impossible, but I feel like it could be done for things like internet cafes or things of that manner - where they could setup one massive server and serve all users.

That sounds just like a baremetal hypervisor, such as VMWare ESXi or XenServer. I've seen ones that are made to work with many "dumb terminals" (such as in schools). Alternatively, you could pass through hardware to the virtual machine, which gives it direct access.

However, a system that is going to support that many stations is likely going to be much more expensive than a bunch of cheap systems.

It kind of exists. What you're talking about is called a hypervisor, which is something that manages VMs. Technically you get "bare metal" hypervisors and "hosted" hypervisors. The latter are ones that run within another Operating System like VirtualBox or VMware. The former are a sliver-thin bit of firmware that runs very close to the metal and doesn't need a full OS. And the two categories can blur a little bit as well as modern chips have support for VMs baked in letting hosted hypervisors get some of the benefits of bare metal hypervisors.

It's quite fun seeing things go in cycles and people independently come up with the same ideas in each iteration (I'm old). That's no disrespect to you - each person comes up with the ideas for good reasons - it's simply nice to see the convergent evolution of solutions. Back in the earliest days, you had massive mainframes which served many users. They weren't virtual (they were hardware monsters), but they'd serve multiple people who all had dumb terminals to the main machine which did all the real processing whilst the terminal was just a monitor and keyboard, primarily.

That's why in UNIX/Linux systems when you open a command prompt, it's called a "terminal" (and old types like me will still use the term when we open Powershell in Windows) - it's because formerly those little windows were what might be on the monitor on your dumb terminal and the backend they were talking to wasn't on the same physical machine, but in another room somewhere. Now you actually run terminals on the same box that is doing the work, but you still have those little windows (at least you do on GNU/Linux systems and with Powershell in Windows) which look like your old screen on the dumb terminal.

Dumb terminals still exist today. But they tend to be called Thin Clients. Okay, I guess a thin client and a dumb terminal are not technically identical but they solve the same problem with the same underlying principles. Look up "Thin Clients" for some interesting reading. There are both GNU/Linux and Windows implementations of this idea. The Windows one is "Remote Desktop" for example and for that, yes - you might have Hyper-V (a bare-metal hypervisor, the thing you described) running a VM for each connecting user. You don't need to have extra ports and cables these days. You can do it all over a simple Ethernet cable, so there's no need for the central system to worry about keyboards connected to where, etc.

Anyway, hope that's of interest. Your idea actually exists, I'm afraid. But kudos for coming up with the solution that other bright people have done before you.