Eric W. Biederman wrote: > I was half wondering if there was a BIOS call we might make in setup.S > to see if we were running under vmware. > > Certainly there are some rough edges to work out here. > We could add one - but I don't want to touch the BIOS code with a ten foot pole. And it still has the problem of having potential future architectural incompatibility. Not that anyone is actively extending the BIOS services, but it is still theoretically a problem. The chicken / egg problem here boils down to - we can't do anything outside the native hardware spec until we are in paravirtualized mode. And we can't detect and enter paravirtualized mode without doing something vendor specific - potentially outside of the native spec. The PCI device solves all this nicely for us, but that approach doesn't work for a true paravirt start-of-day, such as Xen. There are a number of other approaches we could take - a config file setting to deliberately misvirtualize the head.S code, thus magically inserting our hypervisor specific constant in EBX at the right moment, or a boot-shim that sets this up for us. But these approaches are more fragile, error prone, and even more work. Any objections to having a "clean" interface for doing hypervisor probing in addition to magical awakening? The PCI thing is nice, but requires a registered PCI ID for truly safe disambiguation, which not everyone has (Bochs / qemu / L4). Anyone have a better idea? Perhaps PCI spec reserved a vendor range for experimental / software use that we can define for Linux purposes? Zach
