| Message ID | 20250319110152.1309969-5-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | hw/uefi: some bugfixes | expand |
On Wed, Mar 19, 2025 at 12:01:51PM +0100, Gerd Hoffmann wrote: > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > --- > docs/interop/firmware.json | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json > index 57f55f6c5455..76df1043dae9 100644 > --- a/docs/interop/firmware.json > +++ b/docs/interop/firmware.json > @@ -214,13 +214,16 @@ > # PL011 UART. @verbose-static is mutually exclusive > # with @verbose-dynamic. > # > +# @qemu-vars: The firmware expects qemu to provide an efi variable > +# store, via "uefi-vars-sysbus" or "uefi-vars-x64" device. It seems like this would imply mapping.device == memory, as if we had mapping.device == flash, then we would need to extend FirmwareFlashMode with an extra option ? If so, lets document this expectation. > +# > # Since: 3.0 > ## > { 'enum' : 'FirmwareFeature', > 'data' : [ 'acpi-s3', 'acpi-s4', > 'amd-sev', 'amd-sev-es', 'amd-sev-snp', > 'intel-tdx', > - 'enrolled-keys', 'requires-smm', 'secure-boot', > + 'enrolled-keys', 'requires-smm', 'secure-boot', 'qemu-vars', > 'verbose-dynamic', 'verbose-static' ] } > > ## > -- > 2.48.1 > With regards, Daniel
On Wed, Mar 19, 2025 at 11:07:05AM +0000, Daniel P. Berrangé wrote: > On Wed, Mar 19, 2025 at 12:01:51PM +0100, Gerd Hoffmann wrote: > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > > --- > > docs/interop/firmware.json | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json > > index 57f55f6c5455..76df1043dae9 100644 > > --- a/docs/interop/firmware.json > > +++ b/docs/interop/firmware.json > > @@ -214,13 +214,16 @@ > > # PL011 UART. @verbose-static is mutually exclusive > > # with @verbose-dynamic. > > # > > +# @qemu-vars: The firmware expects qemu to provide an efi variable > > +# store, via "uefi-vars-sysbus" or "uefi-vars-x64" device. > > It seems like this would imply mapping.device == memory, edk2 doesn't care if you load it into flash or memory, both cases will work fine. Using flash if we don't actually need it makes things more complicated for no good reason, so yes, I'd go write config files with mapping.device == memory. > as if we had > mapping.device == flash, then we would need to extend FirmwareFlashMode > with an extra option ? There is 'stateless' already for 'firmware image in r/o flash'. take care, Gerd
On Wed, Mar 19, 2025 at 12:30:34PM +0100, Gerd Hoffmann wrote: > On Wed, Mar 19, 2025 at 11:07:05AM +0000, Daniel P. Berrangé wrote: > > On Wed, Mar 19, 2025 at 12:01:51PM +0100, Gerd Hoffmann wrote: > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > > > --- > > > docs/interop/firmware.json | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json > > > index 57f55f6c5455..76df1043dae9 100644 > > > --- a/docs/interop/firmware.json > > > +++ b/docs/interop/firmware.json > > > @@ -214,13 +214,16 @@ > > > # PL011 UART. @verbose-static is mutually exclusive > > > # with @verbose-dynamic. > > > # > > > +# @qemu-vars: The firmware expects qemu to provide an efi variable > > > +# store, via "uefi-vars-sysbus" or "uefi-vars-x64" device. I wonder if 'qemu-vars' is the right name here ? It feels like the specification for such device is effectively defined by UEFI, with any hypervisor providing a impl. Perhaps just call it 'uefi-vars-dev' or some name that's relevant for what EDK2 calls it ? > > > > It seems like this would imply mapping.device == memory, > > edk2 doesn't care if you load it into flash or memory, both cases will > work fine. Using flash if we don't actually need it makes things more > complicated for no good reason, so yes, I'd go write config files with > mapping.device == memory. > > > as if we had > > mapping.device == flash, then we would need to extend FirmwareFlashMode > > with an extra option ? > > There is 'stateless' already for 'firmware image in r/o flash'. What's the behaviour of UEFI if build with JSON vars support, but without QEMU providing any JSON vars backend ? If that happily runs stateless in that case, then we could reuse the existing 'stateless' mode, without having compat trouble with older libvirt that don't know about the 'qemu-vars' feature. We would want to expand the 'stateless' docs to mention that this feature flag indicates optional support for persistence in that case. With regards, Daniel
On Wed, Mar 19, 2025 at 11:37:40AM +0000, Daniel P. Berrangé wrote: > > > > +# @qemu-vars: The firmware expects qemu to provide an efi variable > > > > +# store, via "uefi-vars-sysbus" or "uefi-vars-x64" device. > > I wonder if 'qemu-vars' is the right name here ? It feels like the specification > for such device is effectively defined by UEFI, with any hypervisor providing a > impl. Perhaps just call it 'uefi-vars-dev' or some name that's relevant for > what EDK2 calls it ? 'host-uefi-vars' maybe? Or 'vmm-uefi-vars'? > > There is 'stateless' already for 'firmware image in r/o flash'. > > What's the behaviour of UEFI if build with JSON vars support, but without > QEMU providing any JSON vars backend ? It will panic. > We would want to expand the 'stateless' docs to mention that this feature > flag indicates optional support for persistence in that case. Optional is not possible do due to the way variable store support is organized in edk2. Firmware can't switch between smm and non-smm configuration at runtime for similar reasons. take care, Gerd
On Wed, Mar 19, 2025 at 12:51:16PM +0100, Gerd Hoffmann wrote: > On Wed, Mar 19, 2025 at 11:37:40AM +0000, Daniel P. Berrangé wrote: > > > > > > +# @qemu-vars: The firmware expects qemu to provide an efi variable > > > > > +# store, via "uefi-vars-sysbus" or "uefi-vars-x64" device. > > > > I wonder if 'qemu-vars' is the right name here ? It feels like the specification > > for such device is effectively defined by UEFI, with any hypervisor providing a > > impl. Perhaps just call it 'uefi-vars-dev' or some name that's relevant for > > what EDK2 calls it ? > > 'host-uefi-vars' maybe? Or 'vmm-uefi-vars'? > > > > There is 'stateless' already for 'firmware image in r/o flash'. > > > > What's the behaviour of UEFI if build with JSON vars support, but without > > QEMU providing any JSON vars backend ? > > It will panic. In that case, we must not reuse 'stateless' with such builds, as that's quite different semantics & incompatible with current usage. We would need a new 'uefi-vars' mode, or just declare that we must always use 'memory' not 'flash' for such builds. > > > We would want to expand the 'stateless' docs to mention that this feature > > flag indicates optional support for persistence in that case. > > Optional is not possible do due to the way variable store support is > organized in edk2. Firmware can't switch between smm and non-smm > configuration at runtime for similar reasons. > > take care, > Gerd > With regards, Daniel
Hi, > > > > There is 'stateless' already for 'firmware image in r/o flash'. > > > > > > What's the behaviour of UEFI if build with JSON vars support, but without > > > QEMU providing any JSON vars backend ? > > > > It will panic. > > In that case, we must not reuse 'stateless' with such builds, as that's > quite different semantics & incompatible with current usage. > > We would need a new 'uefi-vars' mode, or just declare that we must > always use 'memory' not 'flash' for such builds. I don't see how 'flash.stateless' is any different than 'memory' (or 'kernel', or maybe 'igvm' some day). If the 'host-uefi-vars' feature is present '-device uefi-vars-$kind' is required, no matter how you load the firmware. What exactly will an old libvirt which does not know the 'host-uefi-vars' feature do in case it finds a firmware.json file with that feature? Play safe and ignore the file? take care, Gerd
On Wed, Mar 19, 2025 at 02:03:09PM +0100, Gerd Hoffmann wrote: > Hi, > > > > > > There is 'stateless' already for 'firmware image in r/o flash'. > > > > > > > > What's the behaviour of UEFI if build with JSON vars support, but without > > > > QEMU providing any JSON vars backend ? > > > > > > It will panic. > > > > In that case, we must not reuse 'stateless' with such builds, as that's > > quite different semantics & incompatible with current usage. > > > > We would need a new 'uefi-vars' mode, or just declare that we must > > always use 'memory' not 'flash' for such builds. > > I don't see how 'flash.stateless' is any different than 'memory' (or > 'kernel', or maybe 'igvm' some day). If the 'host-uefi-vars' feature > is present '-device uefi-vars-$kind' is required, no matter how you > load the firmware. > > What exactly will an old libvirt which does not know the > 'host-uefi-vars' feature do in case it finds a firmware.json file with > that feature? Play safe and ignore the file? No, unknown features are simply ignored. With regards, Daniel
diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json index 57f55f6c5455..76df1043dae9 100644 --- a/docs/interop/firmware.json +++ b/docs/interop/firmware.json @@ -214,13 +214,16 @@ # PL011 UART. @verbose-static is mutually exclusive # with @verbose-dynamic. # +# @qemu-vars: The firmware expects qemu to provide an efi variable +# store, via "uefi-vars-sysbus" or "uefi-vars-x64" device. +# # Since: 3.0 ## { 'enum' : 'FirmwareFeature', 'data' : [ 'acpi-s3', 'acpi-s4', 'amd-sev', 'amd-sev-es', 'amd-sev-snp', 'intel-tdx', - 'enrolled-keys', 'requires-smm', 'secure-boot', + 'enrolled-keys', 'requires-smm', 'secure-boot', 'qemu-vars', 'verbose-dynamic', 'verbose-static' ] } ##
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- docs/interop/firmware.json | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)