Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 31/01/19 13:12, Markus Armbruster wrote: >> Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: >> >>> On 31/01/19 10:41, Markus Armbruster wrote: >>>> Paolo Bonzini <pbonzini@xxxxxxxxxx> 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. Got it, thanks. > 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. I support inviting forks back into the fold, and I understand why "feature parity or go away" would be impractical there. But I'd like to see at least *commitment* to reaching feature parity. > 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...). I would not, simply because secure has always been off by default. >> 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. I'd call that a user interface bug. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
