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
