On 08/05/2012 04:35 PM, Gleb Natapov wrote: > On Sun, Aug 05, 2012 at 04:33:02PM +0300, Avi Kivity wrote: >> On 08/05/2012 03:58 PM, Gleb Natapov wrote: >> > APIC code has a lot of checks for apic presence and apic HW/SW enable >> > state. Most common configuration is when each vcpu has in kernel apic >> > and it is fully enabled. This path series uses jump labels to turn checks >> > to nops in the common case. >> > >> > Gleb Natapov (8): >> > KVM: clean up kvm_(set|get)_apic_base >> > KVM: use kvm_lapic_set_base() to change apic_base >> > KVM: mark apic enabled on start up. >> > Export jump_label_rate_limit() >> > KVM: use jump label to optimize checking for HW enabled APIC in >> > APIC_BASE MSR. >> > KVM: use jump label to optimize checking for SW enabled apic in >> > spurious interrupt register >> > KVM: use jump label to optimize checking for in kernel local apic >> > presence. >> > KVM: inline kvm_apic_present() and kvm_lapic_enabled() >> >> Neat. >> >> During guest boot up, some of these jump keys will change, no? Does >> this mean a stop_machine() or equivalent? I'm worried about real-time >> response or one guest being affected by another. >> > Yes, SW enable bit changes during boot. The jump label triggerable by a > guest are rate limited though. So stop machine will not happen more then > once per second even with malicious guests. I'm not talking about a malicious guest, just a guest that is booting up normally but kills real-time response for another guest (or just induces a large hiccup in a non-real-time guest, but we don't guarantee anything for those). We don't support real-time guests now, but Jan has plans. -- 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
