Re: [Qemu-devel] Testing sysbus devices

[Laszlo Ersek <lersek@redhat.com>]

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.

Thanks
Laszlo