Some additional digging led me to believe that the -bios option actually may work well enough for our use case. Specifically, I tried the following manually:

 qemu-kvm -m 2048 -M q35,accel=kvm,kernel_irqchip  -bios /usr/share/OVMF/OVMF_CODE.fd -kernel /boot/vmlinuz -initrd /tmp/kata-test/initrd.img

and I got the kernel to boot reasonably far. This is not with secure boot enabled, though, so this may not work as intended if what are looking for is SecureBoot. But at least, qemu is smart enough to "do the right thing" when receiving both the -kernel and -bios options.

Setting "low priority" label since this seems to work somewhat OK with the current -bios option.

I was wrong about what the code generates. These seems to be a difference between 1.x and 2.0. According to a discussion with Sandeep Gupta on kata-dev, we have a -bios option for 2.0:

 -bios /usr/local/share/qemu/OVMF_CODE.fd.kata

But a partially correct -drive if=pflash option for 1.x:

 -drive if=pflash,format=raw,unit=0,file=/usr/local/share/qemu/OVMF_CODE.fd.kata,readonly

It's not very clear where that comes from in the govmm code:

func (config *Config) appendBios() {
	if config.Bios != "" {
		config.qemuParams = append(config.qemuParams, "-bios")
		config.qemuParams = append(config.qemuParams, config.Bios)
	}
}

I see nothing there that could produce the -drive option.

/cc @devimc, @sboeuf, @markdryan.

See thread discussing the topic.

Answer from Laszlo Ersek:

"-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.

So pretty clear that we need to change the qemu command-line if we want to support safeboot and SEV.

Ah, so I hit this problem in my SEV patches and worked around it in the follow way: In govmm I create the -drive if=pflash ... for OVMF at the same time as the -object sev-guest .... In kata-runtime, I specify the path to OVMF_CODE.fd in the config using firmware=, same as Bios, but I clear qemuConfig.Bios="" prior to govmm so that a -bios is never appended.

Not the most elegant, but it works with few code changes.

But, no support for OVMF_VARS.fd in this work-around solution.

Do we have any progress on this? Isn't this a requirement for confidential containers to load OVMF firmware? The other features that rely on this working are secure boot or measured boot. Running with the latest kata code the -bios is still used for the OVMF.

@jodh-intel