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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Mar 17, 2016 at 02:28:38PM +0100, Laszlo Ersek wrote:
> 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.

This is where we made a design mistake.  There are 3 kinds of users
adding entries: QEMU, QEMU firmware developers and QEMU users.

And QEMU users could be further subdivided.


> 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