On 11/17/2009 06:50 PM, Jan Kiszka wrote:
I think we're not on the same page here. As I see it, no interface
change is needed at all.
It's true that existing kernels don't handle this properly, which is why
I said I'm willing to treat it as a bug (and thus the -stable treatment
etc.). I admit it's a stretch since this is not going to be trivial
(though I think less complex that you believe).
Putting mp_state into the events structure is reasonable regardless of
this issue (and doable since we haven't pushed it to 2.6.33 yet). But I
want to understand why you think it's needed.
That wouldn't be required anymore with the "always queue" policy.
It makes sense from a grouping point of view... maybe.
But what would you queue at all? Only mp_state, nmi_pending and
sipi_vector?
INIT, too.
Or also all the relevant PIC and LAPIC states that might be
changed asynchronously?
LAPIC cannot support RMW atm because of the timer counts. We may in the
future support LAPIC as well if needed. PIC and IOAPIC need full vm
stop due to many async sources (KVM_IRQ_LINE from multiple threads,
device assignment interrupts, irqfd, lapic EOI messages). vcpu state
has the advantage of being almost completely synchronous.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
