On Thu, Mar 18, 2021 at 01:26:38PM +0100, Pavel Hrdina wrote: > The original text was not explaining what this attribute actually > controls and could have been interpreted as a control switch for the > Secure boot feature in firmwares.
Yep, I've indeed seen people misread it as such. > Signed-off-by: Pavel Hrdina <[email protected]> > --- > docs/formatdomain.rst | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > index a2ea2690a5..c101d5a1f1 100644 > --- a/docs/formatdomain.rst > +++ b/docs/formatdomain.rst > @@ -167,7 +167,9 @@ harddisk, cdrom, network) determining where to > obtain/find the boot image. > in the guest memory the file should be mapped. For instance, if the loader > path points to an UEFI image, ``type`` should be ``pflash``. Moreover, > some > firmwares may implement the Secure boot feature. Attribute ``secure`` can > be > - used then to control it. :since:`Since 2.1.0` > + used to tell the hypervisor that the firmware implements Secure Boot > Feature. s/Feature/feature/ Perhaps: "firmware is capable of Secure Boot feature" > + It cannot be used to enable or disable the feature itself in the firmware. > + :since:`Since 2.1.0` This additional clarification is good. (Nit-pick: not this patch's fault: consistently use "Secure Boot"; I see both "Secure boot" and "Secure Boot".) Address the above only if you're respinning. FWIW: Reviewed-by: Kashyap Chamarthy <[email protected]> > ``nvram`` > Some UEFI firmwares may want to use a non-volatile memory to store some > variables. In the host, this is represented as a file and the absolute > path > -- > 2.30.2 > -- /kashyap
