Re: [PATCH 2/4] KVM: VMX: prepare sync_pir_to_irr for running with APICv disabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/29/21 23:14, Sean Christopherson wrote:
Heh, maybe s/max_irr_updated/new_pir_found or so?  This is a bit weird:

   1. Update max_irr
   2. max_irr_updated = false

Sounds good (I went for got_posted_interrupt).

  	}
-	vmx_hwapic_irr_update(vcpu, max_irr);
+
+	/*
+	 * If virtual interrupt delivery is not in use, the interrupt
+	 * will be processed via KVM_REQ_EVENT, not RVI.  This can happen

I'd strongly prefer to phrase this as a command, e.g. "process the interrupt via
KVM_REQ_EVENT".  "will be processed" makes it sound like some other flow is
handling the event, which confused me.

What I wanted to convey is that the interrupt is not processed yet, and the vmentry might have to be canceled. I changed it to

* Newly recognized interrupts are injected via either virtual interrupt
         * delivery (RVI) or KVM_REQ_EVENT.  Virtual interrupt delivery is
         * disabled in two cases:

	 * 1) If L2 is running and the vCPU has a new pending interrupt.  If L1
	 * wants to exit on interrupts, KVM_REQ_EVENT is needed to synthesize a
	 * VM-Exit to L1.  If L1 doesn't want to exit, the interrupt is injected
	 * into L2, but KVM doesn't use virtual interrupt delivery to inject
	 * interrupts into L2, and so KVM_REQ_EVENT is again needed.
	 *
	 * 2) If APICv is disabled for this vCPU, assigned devices may still
	 * attempt to post interrupts.  The posted interrupt vector will cause
	 * a VM-Exit and the subsequent entry will call sync_pir_to_irr.
	 */

Applied these.

Paolo



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux