On Fri, May 31, 2013 at 03:30:48PM +0200, Laszlo Ersek wrote:
On 05/31/13 03:09, Kevin O'Connor wrote:
Same problem - one can't reliably do an inb(0xe9) on real hardware without risking mysterious failures.
This entire problem seems to exist only if someone runs a SeaBIOS binary on real hardware that was configured like:
- COREBOOT or CSM (ie. not QEMU),
- and QEMU_HARDWARE.
Why would someone set QEMU_HARDWARE ("Support hardware found on emulators") for a binary intended to run on real hardware?
It's common to build seabios with all options enabled and let seabios auto-detect what it can use. That's the intent of QEMU_HARDWARE - it allows one to compile in more drivers and seabios will use them if it detects the corresponding hardware. This does not obviate the need for proper hardware detection though.
If this goes wrong on real hardware, it could require a lengthy session with a soldering iron to fix it. People don't like that.
[...]
What if we replace the inb() in the proposed patch with a cpuid call that detects only KVM, as first step? On KVM it would do the right thing, on bare metal, ditto. On other hypervisors it would err towards safety and could be extended later. What do you think?
The plan was to detect qemu on coreboot via the mainboard vendor/part info that coreboot generates. The plan on uefi was to use the smbios tables to detect qemu. Once detection is in place, the DEBUG_IO support could be made dependent on QEMU_HARDWARE and only activated after detection succeeds.
-Kevin