Re: [Qemu-devel] Testing sysbus devices

[Markus Armbruster <armbru@redhat.com>]

Laszlo Ersek <lersek@redhat.com> writes:

> On 02/19/19 18:55, Markus Armbruster wrote:
>> Stephen Checkoway <stephen.checkoway@oberlin.edu> writes:
>> 
>>>> On Feb 19, 2019, at 10:28, Markus Armbruster <armbru@redhat.com> wrote:
>>>>
>>>> My terminology might be confused...
>>>>
>>>> Let me backtrack a bit an explain my use case.  On physical PCs, the
>>>> single flash chip is commonly configured to have a read-only part and a
>>>> read/write part.  The read-only part holds UEFI code, and the read-write
>>>> part holds its persistent state.
>>>>
>>>> Since our virtual flash chips lack this feature, our virtual PCs have
>>>> *two* of them: one configured read-only, and one configured read/write.
>>>> Cleaning that up would be nice.
>>>>
>>>> The comment "It does not implement software data protection as found in
>>>> many real chips" in both pflash_cfi0*.c might be referring to this
>>>> missing feature.
>>>
>>> I understand now, thank you for explaining. I noticed the comments about software data protection in the code, but I didn't investigate.
>>>
>>> >From a quick look at <https://www.cypress.com/file/195291/download> Table 27 on page 8, I see there are at least 4 different protection modes. I think the most common one (based on my reading of a handful of data sheets for flash chips) is the high voltage one. Essentially, there are sector groups that can be locked/unlocked using high voltage. It seems easy enough to model this by configuring sectors as locked and refusing to erase or program them.
>>>
>>> Software command locking would probably involve implementing a few additional commands.
>>>
>>> I'm not sure what the others are.
>>>
>>> Which locking method do you need?
>> 
>> László, Philippe, what would you prefer to work with in OVMF?
>
> I would strongly prefer if the guest-side view wouldn't change at all.
>
> IOW, I don't have any useful input on extensions to the current command
> set; what matters to me is that OVMF please not be forced to make use of
> the new commands (and that the privilege differences wrt. SMM remain
> functional). We've avoided version lock-in between OVMF and QEMU for a
> great long time now, thanks to the ACPI linker/loader; I wouldn't like
> to see version dependencies reintroduced in other areas.

My grasp on CFI pflash is somewhat shaky.  Philippe, Stephen, please
correct misunderstandings in the following.

We could improve the device model to let us configure a part of the
flash memory read-only.  We could use that to have just one pflash
device suitably configured instead of two.

For guest software that merely reads and writes the memory, no visible
change.

To support updating firmware from the guest, we'd have to implement a
suitable guest-controlled protection mode, but that's not on the table
right now.