Hi Marc, On Sun, Jan 30, 2022 at 12:36:48PM -0800, Marc Orr wrote: > Please let me know if I'm mis-understanding this rationale or missing > any reasons for why folks want a built-in #VC handler. There are a couple of reasons which come all come down to one goal: Robustnes of the kvm-unit-tests. If kvm-unit-tests continue to use the firmware #VC handler after ExitBootServices there needs to be a contract between the test framework and the firmware about: 1) Page-table layout - The page table needs to map the firmware and the shared GHCB used by the firmware. 2) The firmware is required to keep its #VC handler in the current IDT for kvm-unit-tests to find it and copy the #VC entry into its own IDT. 3) The firmware #VC handler might use state which is not available anymore after ExitBootServices. 4) If the firmware uses the kvm-unit-test GHCB after ExitBootServices, it has the get the GHCB address from the GHCB MSR, requiring an identity mapping. Moreover it requires to keep the address of the GHCB in the MSR at all times where a #VC could happen. This could be a problem when we start to add SEV-ES specific tests to the unit-tests, explcitily testing the MSR protocol. It is easy to violate this implicit protocol and breaking kvm-unit-tests just by a new version of OVMF being used. I think that is not a very robust approach and a separate #VC handler in the unit-test framework makes sense even now. Regards, -- Jörg Rödel jroedel@xxxxxxx SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
