From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agXyn-0007oi-Ig for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:28:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agXyj-0000df-Ec for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:28:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agXyj-0000dW-78 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:28:41 -0400 References: <20160316181541.GG12454@HEDWIG.INI.CMU.EDU> <56E9A75D.60603@redhat.com> <1458204143.26199.8.camel@redhat.com> <56EA7C2C.6070905@redhat.com> <1458210166.26199.26.camel@redhat.com> From: Laszlo Ersek Message-ID: <56EAB106.9020905@redhat.com> Date: Thu, 17 Mar 2016 14:28:38 +0100 MIME-Version: 1.0 In-Reply-To: <1458210166.26199.26.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: pbonzini@redhat.com, "Gabriel L. Somlo" , mst@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com 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