Jan Kiszka <jan.kiszka@xxxxxx> wrote on 10/06/2012 15:16:11: > > But you lose flexibility. Remember that if you don't shadow the IDT > > you need at least one dedicated core that never uses ELI to handle > > all the physical interrupts. With the shadow IDT, you could enable > > ELI in all the cores. > > You need to program the preemption timer anyway. Once you leave some > guest due to its expiry, you will re-enable the host IRQs and process them. That' exactly what we do. I never meant to say you don't need the preemption timer. You always need it. However, we "reset" it on every exit. So, if your exit rate is higher than the preemption timer (e.g. due to local interrupts or privileged instructions), then the preemption timer will never fire and you will not increase the number of exits. On every exit, we (actually KVM) re-enable and process interrupts in the host. > That might be an issue. > > My feeling is software-based ELI could be a transitional feature (until > hardware supports it properly) and may focus more on static setups where > you have dedicated cores for guests and separated I/O processing. Yes, we hope the paper and the results will help x86 manufacturers understand the potential/importance of ELI and convince them to support this feature in the hardware (as we described in section 7, Architectural Support). > In any case, I would suggest to start small, mostly self-contained, ie. > with changes that stay within KVM as far as possible. If that is > accepted, you could suggest more sophisticated mechanisms on top, > addressing more use cases. Agree. -- 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
