Add support for SVSM Reboot capability #17
Conversation
SVSM has added a Reboot protocol (Protocol 5) that has a single command (SVSM_REBOOT_EXECUTE, command 0) that will cause the guest to be rebooted. The current command does nothing to any guest state EXCEPT invalidating any pages that had been validated by SVSM at the request of the SVSM guest. Signed-off-by: Richard Relph (AMD) <[email protected]>
|
I am not an expert on this topic, but shouldn't we implement that (also?) in OVMF? |
UEFI supports this ( |
|
The initial target was rebooting from Linux. I agree that rebooting from OVMF is a desirable future feature for SVSM Reboot. Whether Linux reboot would have "just worked" if OVMF reboot was done first is hard to say. Both Linux and OVMF reboot handling is complicated and may involve interactions with QEMU that create undesirable dependencies on QEMU. The Linux reboot handler code has comments and code suggesting it tries ACPI reboot register, then keyboard controller register, ACPI reboot register again, keyboard controller again, EFI, BIOS, CF9 register, and finally triple fault, but is modifiable based on a number of factors such as kernel command line options, detected motherboard/BIOS type, and ACPI settings. |
|
qemu sets the acpi reboot register in the acpi tables generated, so this should be the method used unless explicitly configured otherwise. |
|
I don't understand why we would choose to put QEMU (or any another HV) in the path for anything unnecessarily. Please explain. Wouldn't that mean that we are at the mercy of the HV to do reboot, and how it chooses to do reboot in terms of guest state, or to not do it at all? Today, SNP guests are launched with the QEMU --no-reboot command line option because the HV cannot modify guest state. |
|
I think it just is the current state (I did not check this, but I trust @kraxel on this). My question here is: what are all the places we need to implement this new reboot method to make sure it works reliably? Given that there are multiple configurable paths. |
|
Ah, maybe I misunderstood @kraxel ... I took his note to say we should use the ACPI Reboot Register method, not that that is what is being used. Early on in my effort, Tom recommended the function (native_machine_emergency_restart) that I am modifying here as the focal point for getting Linux to do an SVSM reboot. I believe the patch as it is right now will take precedence over any alternatives. The alternatives - command line, motherboard/BIOS combos, etc. modify the reboot_type variable in advance of entry to this function and I check for being in SVSM mode before reboot_type is used. |
Yes. this was meant as description of the current state. Specifically outlining that by default linux would not try to call into UEFI for reset. So implementing support for this in OVMF is not critical (would be nice to have though). |
|
What else has to happen before this goes in to our linux fork? |
3 participants
SVSM has added a Reboot protocol (Protocol 5) that has a single command (SVSM_REBOOT_EXECUTE, command 0) that will cause the guest to be rebooted. If we are running on SVSM (ie, snp_vmpl != 0), try the new SVSM command. If we aren't running on SVSM, or the command handler doesn't exist (it will not return at all if it exists, even if it encounters an error), then we proceed with the usual reboot methods.