Zachary Amsden <zach at vmware.com> writes: > 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. Agreed. But that case fundamentally needs a different bootloader so the bootloader can poke a value in the linux parameter block. So it is not a problem. > 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? Well there is always the command line option. I really don't see this as being a fundamental problem. In a emulator that can be accelerated we can use the hardware parvirt opts until we detect where we are. In a pure paravirtualized environment we have to know early or we can't boot. Alternatives to a pci device include a dmi table entry, a BIOS table we can scan for, or a standard hypervisor call that gave the hypervisor vendor and revision would be ideal. But that's not a linux problem, except for accepting/rejecting the patch to detect a hypervisor that way. Eric
