From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1age0q-0000en-26 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:55:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1age0l-0000L3-0I for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:55:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1age0k-0000Kj-SE for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:55:10 -0400 Date: Thu, 17 Mar 2016 21:55:07 +0200 From: "Michael S. Tsirkin" Message-ID: <20160317215354-mutt-send-email-mst@redhat.com> References: <1458053080-29170-1-git-send-email-mst@redhat.com> <87fuvpv2jv.fsf@blackfin.pond.sub.org> <20160317143531-mutt-send-email-mst@redhat.com> <56EAB17A.1000400@redhat.com> <1458235026.26199.45.camel@redhat.com> <56EB06FD.1060603@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56EB06FD.1060603@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: Paolo Bonzini Cc: Markus Armbruster , "Gabriel L. Somlo" , Laszlo Ersek , Gerd Hoffmann , qemu-devel@nongnu.org On Thu, Mar 17, 2016 at 08:35:25PM +0100, Paolo Bonzini wrote: > > > On 17/03/2016 18:17, Gerd Hoffmann wrote: > > Hi, > > > >> Alternative: fail on: > >> > >> - a blacklist of etc/* files including etc/system-states, > >> etc/smbios/smbios-tables, etc/smbios/smbios-anchor, > >> etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly > >> etc/boot-menu-wait > > > > I think that fails already because qemu throws an error on duplicate > > firmware entries. > > The problem is that some files are only added conditionally (e.g. > etc/boot-menu-wait). Another problem is that future firmware can run on an older QEMU. Any blacklist-only strategy fails because of that, we need a schema. > > Do we really want shuffle around stuff like this? It means we have to > > support both paths in both firmware and qemu for a quite a while for > > compatibility reasons. > > > > Also note that most stuff in etc/ is used by all firmwares, so moving > > this to org.seabios looks pointless to me, especially as things might > > change over time (i.e. ovmf starting to use cfg options it used to > > ignore first, which is the case for etc/boot-menu-wait IIRC, so it > > started as seabios only but isn't any more). > > Stuff that is used by all firmwares could move to org.coreboot/ or > org.qemu/, but keeping etc/ as a special case is certainly fine by me. > > Paolo