*** Bug 578506 has been marked as a duplicate of this bug. ***

Well, I've been trying to find the "SMBIOS entry point missing" in both upstream and also in dmidecode sources and I found nothing relevant to fix this in upstream but I've noticed a call to address_from_efi() in the dmidecode sources which is trying to access either /sys/firmware/efi/systab or /proc/efi/systab and look for "SMBIOS" string in the file opened and when the string is being found the result is being changed to 0 instead of previous value corresponding to NO_SMBIOS in EFI. Considering this is EFI related and that the HVM guest on ia64 requires xen-ia64-guest-firmware package installed on the host machine and the fact that this firmware is Intel binary blob that's closed source AFAIK so maybe we can be having no way to fix it.

Paolo, you could know something relevant, could you please tell me how it the SMBIOS implemented? Is it implemented in qemu-dm or is it possible it's in the EFI firmware?

Thanks,
Michal

Well, I did testing on one ia64 machine that supports HVM guests now.

This is the host machine:
# dmidecode
  SMBIOS entry point at 0x3fffe000
# cat /sys/firmware/efi/systab 
ACPI20=0x703fd7a0000
SMBIOS=0x3fffe000
#

This is the VTI guest machine:
# dmidecode
# dmidecode 2.10
/sys/firmware/efi/systab: SMBIOS entry point missing
# cat /sys/firmware/efi/systab 
ACPI20=0x2e2e3c2c
#

This seems that the SMBIOS implementation is completely missing in the EFI system table. AFAIK, EFI firmware is the the closed source binary from Intel and also when I turned on the debugging in the guest kernel there was nothing about SMBIOS coming from the EFI shell. Also, there was nothing in the firmware strings on dom0 so we can't fix this since this is coming directly from the EFI shell that we can't change at all.

Closing this as CANTFIX.

Michal