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

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 31/01/19 13:12, Markus Armbruster wrote:
>> Paolo Bonzini <address@hidden> writes:
>> 
>>> On 31/01/19 10:41, Markus Armbruster wrote:
>>>> Paolo Bonzini <address@hidden> 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.