linux-kernel - Re: [PATCH 2/4] KVM: VMX: prepare sync_pir_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <64c3e26a-1f58-c121-3a42-38e70fb6f77e@redhat.com>
Date:   Tue, 30 Nov 2021 09:31:05 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 2/4] KVM: VMX: prepare sync_pir_to_irr for running with
 APICv disabled

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