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. I guess it's fixable, but nobody has stepped up to fix it. Aside: accepting incomplete accelerators, then letting their incompleteness hold back things doesn't strike me as sound policy. 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? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
