On Fri, Feb 4, 2022 at 8:30 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Fri, Feb 04, 2022, Marc Orr wrote: > > On Fri, Feb 4, 2022 at 2:55 AM Joerg Roedel <jroedel@xxxxxxx> wrote: > > > 3) The firmware #VC handler might use state which is not > > > available anymore after ExitBootServices. > > > > Of all the issues listed, this one seems the most serious. > > > > > 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. > > > > Ack. I'd think we could require tests to save/restore the GHCB MSR. > > > > > 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. > > > > Thanks for the explanation! I hope we can keep the UEFI #VC handler > > working, because like I mentioned, I think this work can be used to > > test that code inside of UEFI. But I guess time will tell. > > > > Of all the points listed above, I think point #3 is the most > > concerning. The others seem like they can be managed. > > 5) Debug. I don't want to have to reverse engineer assembly code to understand > why a #VC handler isn't doing what I expect, or to a debug the exchanges > between guest and host. Ack. But this can also be viewed as a benefit. Because the bug is probably something that should be followed up and fixed inside of UEFI. And that's my end goal. Can we reuse this work to test the #VC handler in the UEFI? This shouldn't be onerous. Because the #VC should follow the APM and GHCB specs. And both UEFI and kvm-unit-tests #VC handlers should be coded to those specs. If they're not, then one of them has a bug. > On Thu, Jan 20, 2022 at 4:52 AM Varad Gautam <varad.gautam@xxxxxxxx> wrote: > > If --amdsev-efi-vc is passed during ./configure, the tests will > > continue using the UEFI #VC handler. > > Why bother? I would prefer we ditch the UEFI #VC handler entirely and not give > users the option to using anything but the built-in handler. What do we gain > other than complexity? See above. If we keep the ability to run off the UEFI #VC handler then we can get continuous testing running inside of Google to verify the UEFI used to launch every SEV VM on Google cloud.
