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

From: Paolo Bonzini <pbonzini@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Peter Krempa" <pkrempa@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	Libvirt <libvir-list@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"László Érsek" <lersek@redhat.com>,
	"Alexandro Sanchez Bach" <alexandro@phi.nz>,
	"Justin Terry (VM)" <juterry@microsoft.com>
Subject: Re: [Qemu-devel] Configuring pflash devices for OVMF firmware
Date: Thu, 31 Jan 2019 23:57:14 +0100	[thread overview]
Message-ID: <cb465eba-8c54-af8e-fe0e-ce90f71d213a@redhat.com> (raw)
In-Reply-To: <87munh9gb6.fsf@dusky.pond.sub.org>

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

Paolo