Hi Kevin, David,
On 06/02/13 21:24, Laszlo Ersek wrote:
On 06/01/13 05:35, Kevin O'Connor wrote:
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.
Understood.
I wasn't aware this was pending on me (skimmed src/csm.c). I'll see what I can do in OvmfPkg/SmbiosPlatformDxe.
I posted http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3037, which provides Type 0 and Type 1 tables under OVMF. (Might code up more tables as time allows, but I didn't want to stall this thread here.)
"dmidecode" reports the following in an OVMF Fedora 19 guest, running on RHEL-6.4 qemu-kvm (with no special "-smbios" options passed to qemu-kvm):
# dmidecode 2.12 # SMBIOS entry point at 0x3f8f7000 SMBIOS 2.7 present. 3 structures occupying 163 bytes. Table at 0x3F8F6000.
Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: EFI Development Kit II / OVMF Version: 0.1 Release Date: 06/03/2013 Address: 0xE8000 Runtime Size: 96 kB ROM Size: 64 kB Characteristics: BIOS characteristics not supported UEFI is supported System is a virtual machine BIOS Revision: 0.1
Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Red Hat Product Name: KVM Version: RHEL 6.4.0 PC Serial Number: n/a UUID: 7B20A9F5-274C-0F58-8183-A89538BCA62A Wake-up Type: Power Switch SKU Number: n/a Family: Red Hat Enterprise Linux
Handle 0xFEFF, DMI type 127, 4 bytes End Of Table
Questions:
(1) What field should we key off of in src/csm.c whether the platform is a VM? I would suggest the "System is a virtual machine" bit, but it could be too obvious to be feasible.
This bit is Bit 4 in BIOS Characteristics Extension Byte 2, and available from SMBIOS version 2.3 on.
(2) How should the information be parsed?
(Since "src/csm.c" is SRC32FLAT only, I might even have a chance implementing the parsing.)
I've added SMBIOS parsing code before (see display_uuid() in src/smbios.c). Can I simply copy and customize it, or should it be refactored / reused somehow?
(3) *When* should we parse the SMBIOS tables?
I would say "as early as possible" (debug port access depends on it).
handle_csm_0000 (Compatibility16InitializeYourself()) gets an EFI_TO_COMPATIBILITY16_INIT_TABLE, but that table doesn't provide SMBIOS info.
handle_csm_0001 (Compatibility16UpdateBbs()) gets an EFI_TO_COMPATIBILITY16_BOOT_TABLE. It provides SmbiosTable and SmbiosTableLength.
Unfortunately handle_csm_0001() is not called until quite late in the boot process. I think we should receive SeaBIOS debug output before that point.
I'm attaching a debug port log for illustration:
- It was produced by booting Windows 2008 R2 SP1. (UEFI boot, not legacy boot, but win2k8r2sp1 is buggy and needs CSM even for UEFI boot...),
- SeaBIOS messages were only produced because I had hacked the SeaBIOS config to enable DEBUG_IO in the CSM build,
- the SeaBIOS code in this CSM image is somewhat dated, but that shouldn't detract from main point.
Which is: if we enable debug port access no earlier than handle_csm_0001() -- because SMBIOS is unavailable before that --, then we lose all SeaBIOS debug messages between handle_csm_0000() and handle_csm_0001():
412 handle_csm regs 0x0004ffd4 AX=0000 413 Legacy16InitializeYourself table 4000:8080
to
1515 handle_csm regs 0x0004ffd4 AX=0001 1516 Legacy16UpdateBbs table 480a:0008
Thanks, Laszlo