>>> previous irq injection, next injection will be refused with IRQ >>> window enabled. This is because current implementation will inject >>> exception earlier than irq injection and vmx_intr_assist doesn;t >>> know if previous injected event is external irq (and thus >>> overwrite) or exception. Guest will see lower priority irq get >>> injected rather than higher priority IRQ which >>> arrives later. >>> >>> > > Well, the same thing happens with the code before this commit, > no? If a
Why? The philosiphy here is that the vCPU may receive new virtual irqs, but it will not try to injected. From guest point of view, an old irq (say irq_lo) arrives earlier and right before the virtual instruction boundary, and thus get responsed, while the new high priority irq (irq_hi) arrives a little bit later than irq_lo, but right after the instruction boundary and thus couldn't preempt irq_lo. When guest response to irq_lo, eflag.if=0, so irq_hi can't be responsed at that time although it see irq_hi in IRR. That align with native where it uses micro-code. If we enable pirq before physical irq is delivered, current code has obvious issue (see below comments too). If we insist to move virq deliver out of irq disable. Then we need to avoid 2nd injection of irq. But a big side effect is that frequently higher priority irq such as NIC/IDE irq will arrive right after lower priority irq which will obviously hurt various benchmark and even correctness. I will argue the necessaity of this code movement. A VM Exit/Resume itself probably will block system responsibility (can't deliver irq) in the level of 1K cycles, interrupt injection is clearly far less than this granularity. Probably less than 100cycles. > high priority interrupt arrives after injection, it will have to wait. > The difference is that before this commit, it woke up with the IPI and > now it notices with KVM_REQ_INTR. When physical IRQ is disabled, the physical IPI will not interrupt pCPU, it get delivered only after we resume to guest. > > The window grew larger, but not by much typically. Maybe not much typical, but will frequently happen. With this commit, now the window becomes huge since vcpu deschedule may happen :-( Another serious issue in current code is that due to previous injection, the irq is already consumed, (IRR->ISR). So if there are higher priority IRQs arrive later after the previous injection, now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set. I will guess this one is the major problem source if no-kvm-irqchip & kvm_irqchip still has difference. And I bet it should cause many issues. thx,eddie ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
