From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agY5B-0004QW-NN for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:35:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agY57-00026O-Ah for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:35:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agY57-00026E-2z for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:35:17 -0400 Date: Thu, 17 Mar 2016 15:35:13 +0200 From: "Michael S. Tsirkin" Message-ID: <20160317153203-mutt-send-email-mst@redhat.com> 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> <56EAB106.9020905@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56EAB106.9020905@redhat.com> 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: Laszlo Ersek Cc: pbonzini@redhat.com, "Gabriel L. Somlo" , Gerd Hoffmann , armbru@redhat.com, qemu-devel@nongnu.org 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