> (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? (Of course this *too* would go away if qemu itself prepared all ACPI tables over fw_cfg for whichever firmware the user selects. Then we wouldn't have to duplicate ACPI work between SeaBIOS and OVMF any longer. This task has been on my todo list forever, but it never seems to near the top. Maybe moving to a hermit cabin for a month and sleeping even less would make it happen. I have no clue how others do it.) Thanks! Laszlo ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
