From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5pwI-0004im-M8 for qemu-devel@nongnu.org; Tue, 10 Apr 2018 05:51:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5pwE-0007Sa-PZ for qemu-devel@nongnu.org; Tue, 10 Apr 2018 05:51:46 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59108 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f5pwE-0007S6-J7 for qemu-devel@nongnu.org; Tue, 10 Apr 2018 05:51:42 -0400 Date: Tue, 10 Apr 2018 11:51:31 +0200 From: Gerd Hoffmann Message-ID: <20180410095131.ynii6t3om753vl2t@sirius.home.kraxel.org> References: <20180407000117.25640-1-lersek@redhat.com> <6bfdae78-909f-e7ad-b0f0-25f76dfd81f7@redhat.com> <20180410055914.3ak6niwxjkpph26u@sirius.home.kraxel.org> <52191fc3-e4d1-e780-47a1-311df2a2f99e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52191fc3-e4d1-e780-47a1-311df2a2f99e@redhat.com> Subject: Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Thomas Huth , qemu-devel@nongnu.org, libvir-list@redhat.com, "Daniel P. Berrange" , Alexander Graf , Ard Biesheuvel , David Gibson , Eric Blake , Gary Ching-Pang Lin , Kashyap Chamarthy , Markus Armbruster , Michael Roth , Michal Privoznik , Peter Krempa , Peter Maydell , David Gibson , Laurent Vivier , Mark Cave-Ayland > > Hmm, I'm wondering whenever it is useful to model things this way. It's > > not like you can actually configure things for -bios seabios.rom or > > -kernel uboot.elf. Only pflash allows to actually configure things, and > > there are not that many useful combinations. The code needs > > Read+Execute. Allowing Write could be useful in theory, to allow the > > guest doing firmware updates. But I think nobody actually does that, so > > in practice it is fixed. The varstore can have different permissions, > > but it's only two useful combinations. Either allow access > > unconditionally, or allow access in secure contect (aka smm) only. > > (I hope I understand your point right:) > > I'm also fine if we simply define a fixed (but extensible) set of > mapping methods, basically a new enum type, that simply tells libvirtd > what this firmware *is*. IOW, directly reference a mapping method we > know libvirt implements, rather than give vague hints. > > This could repurpose SystemFirmwareType, but it should become more > detailed. I'm thinking like: > - ovmf: split files without requiring SMM > - ovmf_smm: split files with SMM requirement > - seabios: exactly that > - ... other things others suggest. I wouldn't name them by firmware, that is misleading. Basically we have three cases: (1) single firmware image (seabios, OVMF.fd, ...). (2) split firmware image (OVMF_{CODE,VARS}.fd), where vars can be writable unconditinally. (3) split firmware image, where access to vars should be restricted to smm mode. (2) + (3) requires pflash. (1) works with both pflash and -bios. There also is (4) elf binary loadable with -kernel. Not sure we should include that case. u-boot can be loaded that way. The elf binary seems to be more a side product of the build proccess, I always have both u-boot (elf binary) and u-boot.bin (binary blob loadable with -bios). So maybe we should put aside -kernel for now, and maybe reconsider once a real need for it shows up. So maybe Firmware{Device,Access,Mapping} should be replaced with a FirmwareImageType [ 'single', 'code+vars', 'code+protectedvars' ] ? cheers, Gerd