Avi Kivity wrote:
> 
> Excellent catch, but the fix is wrong.  Instead of partially restoring 
> the ioapic state in the kernel, you should fully save it in qemu.
> 
> This is a trap that many fall into: considering kvm and qemu as one 
> entity and making sure they work well together.  We need to make sure 
> that kvm and libkvm are useful for other userspace programs as well.
> 

Actually, let me ask a question here.  It seems to me that there are two
ways I could go about this:

1)  Change the save protocol so that it saves the relevant information
(i.e. base_address and irr), and then the restore protocol so it
actually pulls this stuff off the wire.  This solution seems more
"right" to me, but it has the downside that we are changing the
over-the-wire information, which will break migration between old and
new versions of qemu.

2)  Just change the restore protocol so that we properly fill in the
missing fields with real, hard-coded values instead of just random
memory.  This has the benefit that it doesn't change the protocol, but
has the downside that we won't reflect changes to base_address or irr
100% properly.  In practice, this doesn't seem like a big deal since
there doesn't currently seem to be a way to change base_address anyway,
and losing the irr doesn't seem to be catastrophic (although I'm not
100% certain about that).

The attached patch implements 2); does anyone have an opinion on which
way to go here?

Chris Lalancette