[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] Configuring pflash devices for OVMF firmwa
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-block] [Qemu-devel] Configuring pflash devices for OVMF firmware |
Date: |
Fri, 01 Feb 2019 09:58:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
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.
- Re: [Qemu-block] [Qemu-devel] Configuring pflash devices for OVMF firmware,
Markus Armbruster <=