[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json" |
Date: |
Tue, 10 Apr 2018 11:51:31 +0200 |
User-agent: |
NeoMutt/20180323 |
> > 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
- Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", (continued)
- Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Thomas Huth, 2018/04/10
- Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Laszlo Ersek, 2018/04/10
- Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Thomas Huth, 2018/04/10
- Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Laszlo Ersek, 2018/04/10
- Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Daniel P . Berrangé, 2018/04/10
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Laszlo Ersek, 2018/04/09
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Thomas Huth, 2018/04/10
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Laszlo Ersek, 2018/04/10
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Daniel P . Berrangé, 2018/04/10
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Thomas Huth, 2018/04/10
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Laszlo Ersek, 2018/04/10
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json", Thomas Huth, 2018/04/09