Re: [Qemu-devel] [edk2] OvmfPkg reset [was: Distinguish between reset types]

[Laszlo Ersek]

On 02/21/13 20:31, Paolo Bonzini wrote:
> Il 21/02/2013 19:24, Laszlo Ersek ha scritto:
>>>> (1) The reset capability that OVMF exports via ACPI -- I agree that I
>>>> should be effecting the 0xCF9 thing in the appropriate table.
>> On a second thought, this will require a new build -D flag, or a PCD.
>>
>> I'm not worried about the ACPI 1.0 --> ACPI 2.0 change in the FADT, the
>> table struct itself forward compatible.
>>
>> However currently we're not saying anything about the reset capabilities
>> of the platform. A client looking at the FADT for reset info will find
>> nothing and follow its own logic, which may or may not include writing
>> to 0xCF9, but we don't have any part in it.
>>
>> If now the FADT starts to claim 0xCF9 on a qemu version that doesn't
>> actually support it, we could mislead the client. Unless we can
>> interrogate qemu about the support (and I think we can't), we'll have to
>> depend on a build-time option. (Or should I shoehorn it into -D CSM_ENABLE?)
>>
>> Jordan, what do you think?
> 
> ACPI tables are hosed enough on some real system that we can assume that
> all guests will fall back to something else---typically a keyboard
> controller reset.

That works for me. Thx.

(BTW I can "plausibly justify" why a BIOS vendor would advertize 0xCF9
(or anything else) in RESET_REG, but deny it by clearing RESET_REG_SUP:
they're probably not sure what hardware the BIOS will be flashed to. So
RESET_REG is a hint for OSPM, but if it doesn't work, "we told you so in
RESET_REG_SUP!" :) Repudiation of responsibility. Maybe we should follow
suit :))

Laszlo