On Sat, 11 Apr 2009, H. Peter Anvin wrote: > > The main thing you could do is drop or virtualize memory accesses to RAM it > should never access in the first place, like some BIOSes which scribble over > random locations in low memory. Please don't. This discussion is just taking us down a rat-hole of more complexity, and _way_ more fragility. I'm absolutely willing to bet that trying to do the BIOS calls will break way more than it will fix. Sure, it will probably work for 99.9% of all BIOSes, but then it will break horribly for some BIOS that tries to do something "clever". SMM has already been mentioned as an example of something that simply isn't virtualizable. Timing is another, very traditional, one. There used to be video BIOSes that simply didn't work in a dosbox-like environment because they had tight timing loops that were coupled to hardware. I can pretty much guarantee that that has gone away as far as the video BIOS is concerned, but the main BIOS? Who the hell knows. Sure, none of the calls we do to the BIOS from the kernel should need anything fancy at all, and maybe I'm pessimistic. But at the same time, I really don't think the BIOS calls are worth that kind of infrastructure. Sure, go ahead and wrap them in some kind of "save and restore all registers" wrapping, but nothing fancier than that. It would just be overkill, and likely to break more than it fixes. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|