On Mon, Feb 7, 2022 at 1:11 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Fri, Feb 04, 2022, Marc Orr wrote: > > 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. > > But how would we know it's a bug? E.g. IMO, UEFI should be enlightened to _never_ > take a #VC, at which point its #VC handle can be changed to panic and using such a > UEIF would cause KUT to fail. Yeah. If we end up with enlightened UEFIs that skip handling some/all #VC exceptions, then using the UEFI #VC handler from kvm-unit-tests doesn't make any sense :-). > > 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. > > I'm not super opposed to the idea, but I really do think that taking a #VC in > guest UEFI is a bug in and of itself. Understood.
