On Thu, Nov 24, 2016 at 01:01:58AM +0100, Laszlo Ersek wrote: > CC Jordan & Mike > > On 11/23/16 23:35, Paolo Bonzini wrote: > > > > > > On 18/11/2016 11:36, Laszlo Ersek wrote: > >> This is v3 of the series, with updates based on the v2 discussion: > >> <http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg02687.html>. > >> > >> I've added feature negotiation via the APM_STS ("scratchpad") register. > >> A new spec file called "docs/specs/q35-apm-sts.txt" is included. > >> > >> Tested with new OVMF patches (about to send out those as well). > >> Regression tested with SeaBIOS (beyond simple functional tests with > >> maximum SeaBIOS logging enabled, I used gdb to step through the new > >> ich9_apm_status_changed() callback to see if it was behaving compatibly > >> with SeaBIOS). > >> > >> The series was developed and tested on top of v2.7.0, because v2.8.0-rc0 > >> crashes very quickly for me when running OVMF: > >> > >> kvm_io_ioeventfd_add: error adding ioeventfd: File exists > >> > >> It is my understanding that there are patches on the list for this: > >> > >> [Qemu-devel] [PATCH v2 for-2.8 0/3] virtio fixes > >> > >> Anyway, the series rebases to v2.8.0-rc0 without as much as context > >> differences. > > > > Hi Laszlo, > > > > sorry for the slightly delayed reply. > > > > First of all, I'm wondering if we would be better off adding a new port > > 0xB1 that is QEMU-specific, instead of reusing 0xB3. > > Sure, I can look into that, if we agree that's the best way to proceed, > for now. (Although I'm not really happy about the new memory region > stuff it would require. :() > > I CC'd Kevin to learn if he foresaw other uses for the APM_STS register > in SeaBIOS.
I don't foresee further use of APM_STS in SeaBIOS. The SMM code in SeaBIOS is specific to QEMU anyway. Also, the current use of APM_STS is so trivial, we could easily remove it from SeaBIOS in a future release (were that desirable). As a general comment - it does seem unfortunate that we keep building adhoc interfaces to communicate information from firmware to QEMU. We have a generic mechanism (fw_cfg) for passing adhoc information from QEMU to the firmware, but the inverse seems to always involve magic pci registers, magic io space registers, specific init ordering, etc. That said, I don't object to your proposal. -Kevin
