Avi Kivity wrote: > 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. INIT should be handled by queuing up the next mp_state. BTW, as we do not inject mp_state changes from user space during runtime, the issue I saw with the current interface is not existing. We just need to add that queuing feature to asynchronous in-kernel mp_state changes, and we should be fine. Let's assume we will have such changes in future kernels: should qemu-kvm and qemu upstream also bother about older kernels and establish workarounds? Because then we need to find a cleaner approach than the current one, and my proposed patch comes into the game again. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
