[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SM

From: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI
Date: Wed, 23 Nov 2016 19:38:35 -0500
User-agent: Mutt/1.7.1 (2016-10-04)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]