Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <64c3e26a-1f58-c121-3a42-38e70fb6f77e@redhat.com>
Date:   Tue, 30 Nov 2021 09:31:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCH 2/4] KVM: VMX: prepare sync_pir_to_irr for running with
 APICv disabled
Content-Language: en-US
To:     Sean Christopherson <seanjc@google.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        stable@vger.kernel.org
References: <20211123004311.2954158-1-pbonzini@redhat.com>
 <20211123004311.2954158-3-pbonzini@redhat.com> <YaVQxZ42Ve6JNIzt@google.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <YaVQxZ42Ve6JNIzt@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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