qemu-system-x86 is on the recommends list which will pull in upstream qemu. Right now the build of Xen modifies the source in a way to look for qemu-system-i386 on the path provided by qemu. This also causes seabios to be used. ovmf would need testing. Ovmf was not really looked at. So for the next release you could file a bug against edk2 which looks to be the source package that provides ovmf.
I would try to make everything use/depend on the same generic parts. I would prefer if we can more and more get rid of any qemu part being built as part of Xen and rather rely on the common qemu package there. As long as qemu-xen-traditional needs to be supported we need to keep that in Xen but long term it should go.
qemu-system-x86 is on the recommends list which will pull in upstream qemu. Right now the build of Xen modifies the source in a way to look for qemu-system-i386 on the path provided by qemu. This also causes seabios to be used. ovmf would need testing. Ovmf was not really looked at. So for the next release you could file a bug against edk2 which looks to be the source package that provides ovmf. traditional needs to be supported we need to keep that in Xen but long term it should go.
I would try to make everything use/depend on the same generic parts. I would prefer if we can more and more get rid of any qemu part being built as part of Xen and rather rely on the common qemu package there. As long as qemu-xen-