Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 31/01/19 13:12, Markus Armbruster wrote: > Paolo Bonzini <pbonzini(a)redhat.com&gt; writes: > >> On 31/01/19 10:41, Markus Armbruster wrote: >>> Paolo Bonzini <pbonzini(a)redhat.com&gt; writes: >>> >>>> On 31/01/19 09:40, Markus Armbruster wrote: >>>>>> Maybe we should just add pflash block properties to the machine? And >>>>>> then it can create the devices if the properties are set to a non-empty >>>>>> value. >>>>> What exactly do you have in mind? Something like >>>>> >>>>> -machine q35,ovmf-code=OVMF-CODE-NODE,ovmf-data=OVMF-DATA-NODE >>>>> >>>>> where OVMF-CODE-NODE and OVMF-DATA-NODE are block backend node names, >>>>> i.e. >>>>> >>>>> -blockdev file,node-name=OVMF-CODE-NODE,read-only=on,filename=/usr/share/edk2/ovmf/OVMF_CODE.fd >>>>> -blockdev file,node-name=OVMF-DATA-NODE,read-only=on,filename=... >>>> >>>> Yes, though I would call it pflash0 and pflash1. >>> >>> Digression... should we put traditional BIOS in flash as well? Only for >>> new machine types, obviously. >> >> The blocker was that very old KVM didn't support ROMD memory regions. >> Now on one hand we don't support those old kernel versions anymore; on >> the other hand we have HAX and WHPX that do not support ROMD at all. > > This is all greek to me. I take it there's something wrong with these > accelerators that makes (read-only?) flash memory not work, even though > the read-only mapping we now create for traditional BIOS works. Weird, > but I'm of course willing to take your word for it. Yes, as I wrote in the other message even read-only flash memory supports commands, and these accelerators do not support direct reads + MMIO writes on the same memory slot.

At least I checked HAX code and it doesn't; I don't know about WHPX. > Aside: accepting incomplete accelerators, then letting their > incompleteness hold back things doesn't strike me as sound policy. Yes, there is a balance to be found between that and accepting features from known out-of-tree forks, in order to help these out-of-tree forks not remain forever on very old releases.

However, another important question is---if you changed the default from -bios to -pflash, would you also flip secure from off to on? Only TCG and KVM supports SMM, and it's quite unlikely that the other accelerators will support it (there are also "philosophical" debates behind that choice...).

> Do we reject these accelerators when the user asks for firmware in > flash? Or do we let the guest run into some more or less obscure > failure? For HAX it just fails to boot I think.