Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

[Laszlo Ersek]

On 03/17/16 11:22, Gerd Hoffmann wrote:
>   Hi,
> 
>> Occasionally, yes.
>>
>> - "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties
> 
>> - "opt/ovmf/PcdSetNxForStack" controls whether the stack is made
> 
>> - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which the
> 
>> In downstream, we have two more (same purpose but separately for ARM and
>> x86):
>> - opt/aavmf/PcdResizeXterm
>> - opt/ovmf/PcdResizeXterm
>>
>> - Another flag I might expose later is "PcdHiiOsRuntimeSupport". This
> 
> I think we should probably move those out of the opt/ namespace space,
> as this is reserved for user-defined files.
> 
> I think either "etc/efi/"

This is more or less what Paolo suggests.

It confuses me.

I have now re-read the last section of "docs/specs/fw_cfg.txt" to make
sure my current mental image of the original idea has not diverged from
the actual original idea. I don't think so.

So, "user defined files" exist so that users can control "stuff" with
them, without QEMU's knowledge. OVMF is "stuff". Just because it's
firmware, it remains "stuff". Whatever Gabriel wants to control with
such fw_cfg files in the guest, is also "stuff". I don't see any
difference between a user controlling an ad-hoc application of his with
"opt/blah1", and controlling OVMF behavior under "opt/ovmf/xizzy". If
the user tries to control his own app by choosing the name
"opt/ovmf/xizzy", that's *his* fault. "opt/ovmf/" is not a prefix
someone comes up with by chance.

We meant just two partitions of the namespace. "opt/" and non-"opt/".
The latter belongs to QEMU, the former belongs to everything else, and
the subdivision of everything else doesn't belong into QEMU. OVMF is
part of everything else.

If we're paranoid about it, we can make a recommendation that each user
pick "opt/UUID/..." for himself, running "uuidgen" and then sticking
with the output for his own stuff. That will guarantee that no conflicts
will be seen. OVMF could be adapted to that as well. (The only snag with
uuidgen is that it would leave only 56 - 4 - 36 - 1 == 15 characters for
the actual knob name.)

Choosing "etc/" for such files of OVMF that are passed in with the
-fw_cfg switch would be the textbook example of violating the original
idea, because etc/ is heavily populated by QEMU itself.

> or "efi/" is useful (so we don't have
> different names on ovmf and aavmf).

I dislike efi/. It suggests that it controls some features that all UEFI
implementations offer.

> Possibly add "pcd/".  Maybe even
> support setting *any* pcd via "efi/pcd/$name" (just an idea, not sure
> whenever that is useful and is possible without being too invasive).

It's all of: too invasive, not always useful, and not flexible enough.
Knobs should be exposed (with their different value domains) on a
case-by-case basis.

>> - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which 
> 
> Hmm.  Leave as-is for now I'd say.

Will do.

>  If we decide to keep it we should
> probably rename it and place it below etc/, next to reserved-memory-end.
> Export the size in bytes, like reserved-memory-end does.  Add an option
> to qemu to set it, so you can specify the size as "32G" using the
> standard qemu size parser.

I certainly don't disagree with this, but if it goes under etc/, and --
hence necessarily -- also gets its own command line option, then SeaBIOS
should probably adhere to it as well (or the QEMU manual should state
that this option is also firmware specific).

Thanks
Laszlo