Hi Christophe! On 01/06/21 16:11, Christophe de Dinechin wrote:
Hello Laszlo,
Happy New Year!
Same to you :)
I may need to pick your brain a little regarding an issue someone testing AMD SEV ran into with Kata.
Basically, here are the questions I have:
1) Is it OK to pass an OVMF firmware to the -boot option of qemu? What about SecureBoot in that case?
2) Are there any expected behavioral differences between booting with the -bios option and using a -drive if=pflash option? In particular, anything that could prevent SEV from activating in the guest kernel?
3) Knowing that in the Kata case, we don't care about anything persisting across reboots, is there any problem passing only the OVMF_CODE.fd image readonly using the -drive option, without having an OVMF_VARS.fd? Asking to see if we need to create an OVMF_VARS.fd for each container.
If you need a bit of context: https://github.com/kata-containers/kata-containers/issues/1231 and http://lists.katacontainers.io/pipermail/kata-dev/2021-January/001638.html
"-bios" should never be used with OVMF. If you don't need non-volatile UEFI variables to persist from one boot of the domain to the next, that's fine; in that case, please use a throw-away regular file for the variable store pflash chip. this file should be instantiated from "OVMF_VARS.fd", if you don't want the Secure Boot operational mode enabled right off the bat; otherwise, please copy (create) the domain's varstore from "OVMF_VARS.secboot.fd", before launching QEMU. We have never tested SEV with "-bios" (well, because "-bios" is wrong to use with OVMF in the first place, regardless of SEV); and yes there have been SEV-related changes, specific to the flash driver in OVMF. (QEMU too received SEV-related changes around the parts responsible for loading OVMF, in "hw/i386/pc_sysfw.c".) The particulars of a SEV failure, when using "-bios", aren't even worth investigating -- please try to reproduce the issue first with two pflash chips. Thanks! Laszlo