On Mon, Sep 16, 2013 at 07:58:42PM +0300, Gleb Natapov wrote:
On Mon, Sep 16, 2013 at 03:14:45PM +0200, Gerd Hoffmann wrote:
That is a purely theoretical thing. In practice seabios mist likely has to be changed for one or another reason.
It's not have to be this way if Seabios would check for specific HW features instead of checking for QEMU. For instance if discovery of fw_cfg will not depend on QEMU detection other userspace can emulate and it will be detected without changing Seabios.
For the most part, this is what SeaBIOS does today. There are very few places in the code that check CONFIG_QEMU.
In particular, Gerd has already changed the fw_cfg support to not depend on CONFIG_QEMU.
Also note that in theory seabios should not need to care at all whenever it runs on kvm or tcg. In practice qemu has slightly different behavior with kvm enabled and seabios needs adapt to that. That alone is reason enougth that supporting other kvm userspace very likely needs adaptions in seabios, unless your theoretical[1] other userspace is bug compatible with qemu here.
I see only one thing that is done based on KVM detection and the logic would be correct for other userspaces that do not provide e820 map.
One of the places where CONFIG_QEMU is used is in determining how to get the memory map. Any new emulator that uses SeaBIOS is going to have to define the mechanism for passing the memory map and that's going to be a SeaBIOS code change anyway. (It's different on qemu, xen, coreboot, and csm.) It's theoretically possible to use the QEMU memory map passing (magic cmos variables), but if that path is taken one might as well just enable CONFIG_QEMU then..
-Kevin