Hi, > > I can't see any support for Cloud-Hypervisor in OVMF. > Right that currently OVMF is not supported by Cloud-Hypervisor in Td guest. > But we're > planning to support Cloud-Hypervisor to launch OVMF in Td guest and have done > some POC.
> > Also FreeBSD's bhyve doesn't support fw_cfg either and has its own ways to > > detect memory. Cloud-Hypervisor can surely do that too. > > > > So, why does this matter? > Yes, Cloud-Hypervisor has some POC to launch OVMF in Non-Td guest. In that POC > Cloud-Hypervisor leverage a 4k page in MEMFD and pass ACPI data to guest > Firmware in that memory. > https://github.com/cloud-hypervisor/edk2 "ch" branch > https://github.com/cloud-hypervisor/edk2/commit/52cb72a748ef70833100ca664f6c2a704c28a93f Post the Cloud-Hypervisor patches to the list for review if you want them included in OVMF. out-of-tree patches lingering in some random branch @ github do not matter. > > > https://github.com/cloud-hypervisor/cloud-hypervisor > > > TD Hob list gives Cloud-Hypervisor a chance to pass information to guest > > firmware. > > > For example, ACPI can be downloaded from QEMU via fw_cfg to firmware. > > > But Cloud-Hypervisor cannot pass ACPI via fw_cfg. In this situation, > > > TD Hob can resolve this problem. > > > > Sure, but again, why does this matter? For qemu? > I don't quite understand the question here(For qumu?). Well, each VMM has different interfaces for guest <-> host communication. qemu/kvm uses fw_cfg. Xen and Bhyve have something different, and Cloud-Hypervisor seems to have something different again. > What I mean in my last answer is that TD Hob can resolve the problem > when the host VMM doesn't support fw_cfg communication mechanism. Sure. If Cloud-Hypervisor wants use that (for both TDX and non-TDX probably), fine. Submit the patches and we can discuss details. But why do you want switch qemu/kvm from fw_cfg to TD Hob? > > I don't like the idea to have TDX take a completely different code > > paths. That increases the code complexity and makes testing harder > > for no good reason. > TD Hob is not a completely different code path. This is a useful > supplement to the fw_cfg which is not supported by some host VMM. The code uses that unconditionally though and not only in case fw_cfg is not available. > From another perspective TD Hob can be treated as a set of launch > parameter by host VMM. It provides the flexibility for the host VMM > to bring up the guest firmware with more parameters. I'm wondering what you are running on the host? I assumed we are discussing qemu/kvm as VMM, is that actually the case? Or do you use Cloud Hypervisor? qemu doesn't provide a TD Hob. So, when running qemu you probably have some out-of-tree patches adding that. Have you submitted them upstream? What is the status? I suspect you need to come up with some *very* good arguments to get that accepted. The need to bring parameters to the guest firmware is the reason why fw_cfg exists in the first place ... > Another benefit is that TD Hob can be measured into some secure > register (for example, in TD guest it is RTMR registers, like the TPM > PCR) so that attestation can be done based on the measurement. fw_cfg is measured too (according to one of the tdx pdfs, don't remember which one). take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#79791): https://edk2.groups.io/g/devel/message/79791 Mute This Topic: https://groups.io/mt/84837914/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
