OVMF doesn't respect -acpitable QEMU parameter

[alexfv]

QEMU allows to insert various vendor-specific ACPI tables, such as SLIC and MSDM, by -acpitable command-line parameter. SeaBIOS adds this tables to ACPI information, but OVMF doesn't.

[lersek]

OVMF's ACPI linker/loader is certainly supposed to support ACPI tables that are passed to QEMU explicitly on the command line. For example, here's an independent report that it worked for the same exact purpose as yours: http://forums.fedoraforum.org/showthread.php?t=298236

Considering how old this report is, I'm closing it.

If you can still reproduce the issue, please reopen the item, and also upload your SLIC and MSDM tables, plus paste the exact QEMU command line and/or libvirt domain XML you are using. (You are certainly encouraged to hex-edit the actual license key out of the ACPI blobs, but I'll need structurally identical tables.)

[lersek]

Sigh, obviously I have no permission to close this issue. Second, why is this issue tracker view jumping around the page when I scroll to the bottom in Firefox? Extremely annoying and broken. Is github incompatible with the "It's All Text!" firefox extension? If it is, that's a deal breaker for me.

[alex3kov]

I'm having the same issue (with OVMF, that is).
Qemu command is

qemu-system-x86_64 -nodefaults -nodefconfig -name Windows7 -enable-kvm \
-machine type=pc,accel=kvm -m 3072 -vga std \
-serial none -parallel none -rtc base=localtime \
-cpu host -smp sockets=1,cores=4,threads=2 \
-smbios file=/vms/dmidecode.bin \
-acpitable file=/vms/acpi_slic.bin \
-acpitable file=/vms/acpi_msdm.bin \
-object rng-random,id=rng0 -device virtio-rng-pci,rng=rng0 \
-usb -usbdevice tablet \
-drive if=pflash,file=/vms/ovmf_x64.bin,format=raw \
-drive if=virtio,file=/vms/disk_diff.qcow2,format=qcow2,media=disk \

Where dmidecode.bin file is generated by dmidecode --dump-bin dmidecode.bin, acpi_slic.bin and acpi_msdm.bin are simply copied from /sys/firmware/acpi/tables/.
I need to present hw information as close to real hardware as possible, including SLIC/MSDM tables. To verify the visibility of ACPI tables to a vm I use ACPICA tools https://www.acpica.org/downloads/binary-tools - inside qemu VM it reports only BOCHS tables.
On the other hand, Windows 7, virtualized with VirtualBox (there's an internal command to present 1 ACPI table to a VM), successfully reads provided SLIC table.
I'm ready to provide additional info and tests. Qemu 2.4.1, OVMF 18419.
Can we please reopen this issue?

[lersek]

I agree that this should work.

Please try to reproduce the issue with a fresh OVMF build.

Please upload the MSDM and SLIC binary files (with the identifying information in them overwritten with whatever you'd like, e.g. zeroes). Please also upload the smbios binary file.

Thanks
Laszlo

[alex3kov]

@lersek
Reproduced the issue with ovmf-git 17551.d764d59.
SLIC file fails digital signature (checked with Slic Toolkit) after replacing all IDs with zeroes. Github doesn't take binary files, here they are - http://www.4shared.com/zip/1JBDp9d6ba/slic_bios.html

[lersek]

@alex3kov

Sorry, that download link doesn't work for me. It seems to want me to disable my adblocker, which I won't do. Here's some alternatives:

• Please look up my email in the edk2 commit log or the Maintainers.txt file in edk2, and send me the files directly.
• Please uuencode (with the --base64 option) the zip file, and paste it here as a comment (formatted as "code"). I can uudecode it.
• Please upload the zip file to your google drive (or some such, if you have one of these fashionable things) and share the link to the file.

Thanks.

[alex3kov]

@lersek here we go:
http://pastebin.com/pgx1eNXm

[jljusten]

@lersek, @alex3kov: Seems like your can attach files directly to issues. (See text below the comment box.)

[alex3kov]

As I mentioned before - Github doesn't take binary files.

[jljusten]

@alex3kov: Ah, yep. Sorry, I missed that.

[jljusten]

@lersek: Let me know if I should re-open this issue. By the way, after the svn=>git transition all of the package maintainers should be able to close/re-open.

[lersek]

@jljusten: please reopen this one, yes. Thanks!