Open chris-oo opened 5 days ago
daprilik
commented
4 days ago Unless we want to swap one hack for another hack, supporting configurable UEFI boot entries is a bit of a hairy problem in its own right... See #162 (which talks about OpenHCL in Hyper-V, but much of the nuance / plumbing applies to OpenHCL on OpenVMM as well)
smalis-msft
commented
4 days ago Note that the 'hack' in question for supporting this looks something like having a vmm test call https://github.com/microsoft/openvmm/pull/381 instead of the normal run, waiting for the VM to issue a reboot, resetting it, then waiting for pipette to connect on the subsequent boot. This is not a flow that takes up a lot of code or that is particularly hard to support, but it certainly is annoying. We could even hardcode this expected flow into a petri helper if we felt so inclined (run_with_shim_reboot_expected or something).
chris-oo
commented
4 days ago UEFI has a way to support relative paths, where you only need to specify the HD guid and partition ID or something. You don't actually need to know the device, and so as long as we know the disk id and such we can easily do that without needing to know the full device path.
daprilik
commented
4 days ago The hard part isn't really with the format of the var - rather, its all the infrastructure to set / get those vars (boot order, and otherwise)
For some reason, shim wants an explicit boot entry in UEFI if a tpm is present. If it's not present, it writes one, then issues a reboot. This breaks certain tests as the test infra does not expect a reboot, which we can hack around for now.
Instead, we should figure out how to create a UEFI relative path boot entry and have petri set that up. This way, we don't need these hacks to support multi reboots because shim wants this behavior.