From nobody Sun Jun 14 04:09:40 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8574E37C0FC for ; Sun, 3 May 2026 20:17:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777839434; cv=none; b=rZM6Smm1kdOwneXF163xt5DNhy8eN72L2XNwupXAI+i6iHn/mjgFP/ed6huzY36bgv3u7hvJqOSZxp4ELtXrwPr/h547WaPlw/fVnMB7a4ye4hivYvMhSkcFCISFup3IitLnf1N8DLrdHSUMtdTaeOYIA8hFWWS0YVKU0KS7hTQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777839434; c=relaxed/simple; bh=giOp6gfjXieT1/b6xUERpdXrEm1QCvEoZYYLScyzdfw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jE5dwGjvkdItOGUBSTJcRumD4mD5oMfioc2aVKLaALf16CGc9VV38HhRjThna+oZCczrIwUX6Q+6ivB33rySxpL607x0qCmNwUGBssOkEuTqd/9tJaPceI+o3XKZqYN5GrVE1Cy4BLmiQFQt1ZVVh9M7BzvhESWPMJvHGZ6fcJs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=J/3/trsG; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=KRu8udzO; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="J/3/trsG"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="KRu8udzO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777839430; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I+gTtkSHsc/58H8jQY/bg4el9R2aQOy+A7eA/4Fm6GM=; b=J/3/trsGn2hzEUbC3/GMZgc4LdTjvdzmeqOq6Q5ubmlZpwa+SFppzYnKcKSW4yk8cxB70N X0Uz614mUVYWTKMQ+NiSFi3qtNI2Ile243xxpqHf9Fk1JkzI8ZiQdh1Ujv0PrmyrkcoICk vD+G3lY9QLWUp6owciPFzIciY+P5nUs= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-180-P1Dyr-1wMpygIhXY1uLmAQ-1; Sun, 03 May 2026 16:17:10 -0400 X-MC-Unique: P1Dyr-1wMpygIhXY1uLmAQ-1 X-Mimecast-MFC-AGG-ID: P1Dyr-1wMpygIhXY1uLmAQ_1777839429 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-43d789cebcfso2796085f8f.1 for ; Sun, 03 May 2026 13:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1777839428; x=1778444228; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=I+gTtkSHsc/58H8jQY/bg4el9R2aQOy+A7eA/4Fm6GM=; b=KRu8udzODktaKGvUl+tthBmiysiyCM4ngAw5phIGnOoGcBNJbnawf5h+u4e2yVAOcd ct4+LThSibl0aaqG8Gvc2znLy/s/jUgDOW6NFth+BugpD0NV3Rhajtq2IhTvJUXyszai yOiImZ7x+A9xzCO3/X5hbcwWyiJvYx38j9ekdWbPIoEObYC0LN98RKyHNkxhB01D3LPx EO35Y+n3RjRJse9uPn3iTzvlYyB2cDZuRWZTeUonjEb8GmxJy3vvuKNFb5VwLS+t6FF+ Nv3s605jXdUIyZgANTNo90fxqakj4iLmY05hGJOD0WZR2VdHnYsLuIoXH/GjEBDa+twO r2Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777839428; x=1778444228; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=I+gTtkSHsc/58H8jQY/bg4el9R2aQOy+A7eA/4Fm6GM=; b=ETea57JQojuwoYCcOnNW+Z3RWNXKdziWe7ymHf6wJiWjmYQ3N6QdCDzZ+M13TJmp5x AC/8rEZuor4sf498hDp4sEr/jECKO7oHpF+RqKnKqQPhBfXB7HknltHFZs+HDSI+5D9W V2G/nhMdUX457JSagWr7U7bhixDtukoCBY3ZFmAMae04Ar5eoOQVJkcM8t8hB53uYF0n m9DQ77KMXZpK6QUUBw5RNyDcSVSOjHzyE4SC+3oJ36AS1Ad+kQu64jiG8o67vqIm2ML5 2G25lHuepFKsQRMpJdmoxNWe7ecz7xusru64ifbmeZm9tB6YFE4u5xtc5eYw1bOcg5gX yFqA== X-Gm-Message-State: AOJu0YzG06vHfZj6x0lzG4L0bm+o7/tFWuqFxDLLQiqsB0kQqt/F7e8/ CPkGui5IEhsAcYw0kkYmNBsQSuBWRrnFyQnh5B2qgdNyILLBwtZUBUm0sMN6OV0mgW/BWXk5ucj IG2SW8jcMFJGMivdxz2QyF5PN/Qki6VbpAHv9tVm4XvF4svQ7U3DhdzVu/tiBavjU4nAlgHJBMu sg+J1OMKgJcIf0R8oznWfZff31BEdWHLjpvVpQy/duzN48Lkg8HA== X-Gm-Gg: AeBDietVGdDHgX3rwxuI8s6sqBLRKv8Tke5ZltPbO48BpLVQYGeNt6cc8gorfdofgI/ AlKjn8cnX/RTyqQjz6zbebKw25XfzKoDtnt4My69ayDRft9SaOScKgki7RGsaRlYQ7AYuXgF8Rn EtpH3fM1DQnQb8A2lg3HyhuWg7ZoR9iNnXrZ7tuxzKAfsxg4eEBw4iYEO/sI2RfXhkpZpVhsLqp /bHv2liljlVj/gIBSLF/GQTxQMR/OPLrD7mEqC1W23oJ784Jp//5vaE6UlQ7rCmUO1k1Luh5mTP +XZog6xKLDqDIrRxJWssxjl1e1+yDJ59kmoe3tQv/Wepuu6oqJUjrPlc14zLoVrdNV59oNx8bq1 Mdo2u6jqZH85wxehqH6+ZMOZE/4iS3omZkUPL5bxcKIPU+dDDKOvvaX9ZeKFBA5e9/k7lePY+Xi QjLUcXgndQGit5BWHeldMndUmE2eApFhxZFS8= X-Received: by 2002:a05:600c:4f13:b0:486:faa8:9e4 with SMTP id 5b1f17b1804b1-48a970fda7bmr122451375e9.12.1777839428022; Sun, 03 May 2026 13:17:08 -0700 (PDT) X-Received: by 2002:a05:600c:4f13:b0:486:faa8:9e4 with SMTP id 5b1f17b1804b1-48a970fda7bmr122451145e9.12.1777839427631; Sun, 03 May 2026 13:17:07 -0700 (PDT) Received: from [192.168.10.48] ([151.49.85.67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-44a9879ef45sm21476274f8f.32.2026.05.03.13.17.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2026 13:17:06 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: chenyi.qiang@intel.com, Farrah Chen , stable@vger.kernel.org, Sean Christopherson Subject: [PATCH 1/2] KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty Date: Sun, 3 May 2026 22:17:02 +0200 Message-ID: <20260503201703.108231-2-pbonzini@redhat.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260503201703.108231-1-pbonzini@redhat.com> References: <20260503201703.108231-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Fall back to apic_find_highest_vector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR. In a nested VM stress test, the following WARNING fires in vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending interrupt but the subsequent kvm_apic_has_interrupt() (which invokes vmx_sync_pir_to_irr() again) returns -1: WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_n= ested_events+0x6bf/0x6e0 [kvm_intel] Call Trace: kvm_check_and_inject_events vcpu_enter_guest.constprop.0 vcpu_run kvm_arch_vcpu_ioctl_run kvm_vcpu_ioctl __x64_sys_ioctl do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction: 1. pi_test_and_set_pir(vector) -- sets the PIR bit 2. pi_test_and_set_on() -- sets PID.ON The following interleaving triggers the bug: Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr): B1: set PIR[vector] A1: pi_clear_on() A2: pi_harvest_pir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=3D0 (1st sync returns correct max_irr) B2: set PID.ON =3D 1 Target vCPU (2nd sync_pir_to_irr): C1: pi_test_on() -> TRUE (from B2) C2: pi_clear_on() -> ON=3D0 C3: pi_harvest_pir() -> PIR empty C4: *max_irr =3D -1, early return IRR NOT SCANNED The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpu_enter_guest() iteration), but the incorrect max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle. Fixes: b41f8638b9d3 ("KVM: VMX: Isolate pure loads from atomic XCHG when pr= ocessing PIR") Reported-by: Farrah Chen Analyzed-by: Chenyi Qiang Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini --- arch/x86/kvm/lapic.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index e3ec4d8607c1..5ee14d6bc288 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -669,12 +669,14 @@ bool __kvm_apic_update_irr(unsigned long *pir, void *= regs, int *max_irr) u32 irr_val, prev_irr_val; int max_updated_irr; =20 + if (!pi_harvest_pir(pir, pir_vals)) { + *max_irr =3D apic_find_highest_vector(regs + APIC_IRR); + return false; + } + max_updated_irr =3D -1; *max_irr =3D -1; =20 - if (!pi_harvest_pir(pir, pir_vals)) - return false; - for (i =3D vec =3D 0; i <=3D 7; i++, vec +=3D 32) { u32 *p_irr =3D (u32 *)(regs + APIC_IRR + i * 0x10); =20 --=20 2.54.0 From nobody Sun Jun 14 04:09:40 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C178737C910 for ; Sun, 3 May 2026 20:17:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777839438; cv=none; b=J0xYo6W/+OBg3h4kpkH8sCehGrPkrFBOTTPy7VXjfA4gSjEzRyUOAJdMcwypFt8HAlQL9VI2avqNEr5N57eGM+3/Z8sEFs7KvChG5iDTyobVKZGwNSMsii7Sj6A0izKLwHWU0TlXG9xOYfdxu4bwezOD10UVMdKTzh4vyK05ULQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777839438; c=relaxed/simple; bh=vHGELw01CfVMPo3oS+tSKZTwU3Pk22EiGyP+znUd6d4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VFkiYtXnhZw1Qk2CBfp55fFtXCCxaWGJbHJlhIQ8n0jksCL3/gnZ1mVaOeHVo/tszJNVB3ZiNGpSl/cnxOcj6bG7TfFhIxg5uISrUgS1q7nYuBHBFtS4HhdYm3ACcAmIs9MZZoCKadD0g8BfknrLk8F37jl6jtlkU4zraKFk8dI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HDCS4LMy; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=FWO0CdGI; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HDCS4LMy"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="FWO0CdGI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777839434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qoof0QP2ICD/jTmNNrG4fkHvjJrYgerZ9Ct4SB/uRWE=; b=HDCS4LMy0cPcEXAQjY5pXmgMHpUNDliVSmMRjDNMeUZCM8hz0+LXmbCD6TLeMk4Ra59a9S SKF2adHIfHnxZpsMoOI3YpWhxforVfdwhOXYgF9O7RwtM51RoB8jKHb0dnFVZVJAWq9fmj HbZdnWxqazz+Uo//T09FjGcORwh4YLk= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-512-Bp8jyCLKOH6P8-mFRRknQQ-1; Sun, 03 May 2026 16:17:13 -0400 X-MC-Unique: Bp8jyCLKOH6P8-mFRRknQQ-1 X-Mimecast-MFC-AGG-ID: Bp8jyCLKOH6P8-mFRRknQQ_1777839432 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-44696b11265so3692563f8f.0 for ; Sun, 03 May 2026 13:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1777839431; x=1778444231; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qoof0QP2ICD/jTmNNrG4fkHvjJrYgerZ9Ct4SB/uRWE=; b=FWO0CdGIKTxTmy2iOyzR8+104e73j/XCa1HZLc5av82y5EuJ1+zZdGUweT7G2Q/Cgg MLFYL307E4Uy2QCWOsPfsiIHf9VyedLVtdhiaDBq0oRv+lXeb8TJ6fW7DCXsz5GBawNd TS83+2aq9GtpqAgMb/jczGYAvpnTiDWpxsC6WSifgLvGg5Ga3DCQYfETGzMAh+Kb2zc/ 35BFwO0ZLeniVdEwaXj2aFt+DV0oxBOl0CCmGZbIuz4SQT6zNvVhf7So/2KpWLBrgP2a /Tcq44j1wnWCIirmxV8VHsglJvCQMJ5w8qlKyTxmZa1pEhbLOK/4SYEg0vS6LokqGmn3 62iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777839431; x=1778444231; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qoof0QP2ICD/jTmNNrG4fkHvjJrYgerZ9Ct4SB/uRWE=; b=IR5hVQtMhrA4SAyLR6+1O/fUY0FUDx7v03NTO1AKInpJl+VcywwgD3GXyHHH4QdY/4 S3TNgnrUa8jBvP+3mtyfPi2vNDpNtbb4IrkuPOYkQI1v7ebHJvqVIP+R/X8fCVX7KrUT lQcJj5QMAeCmBmPQ0fzflJGO1tQZvpAC5V/96zfj6HBst1LICv1m6H4T0ynM9IZ7bqer dxOjEN7Q2CvDH6Lwdkxm4ynuCjZ8AW6bfsl2hyxzyVFQPeTwK8oiTsbqzYG5oJNkQcr3 k7RxWc5NhNXw5FRyJZz8YXSTHdQeszSkJtfvv9lft3vwrpLN8Z1ZDNWPJq8VfdUBxeoD BCvQ== X-Gm-Message-State: AOJu0Yxh3mYqoIeVVHXr87MgcTJwrLoNjn0sQ+OGQVgXTPB66by7DqLk XronwaVExHOJGDO5AVeNWywmL2/GOIhW9cOuVVgfjSY5FxHE5Ku3408ckEV+DanZDJ1YL0Sg33k 20xnJ3z4GDBtBXu1MRMyhJ6I+8MvnTN8kEKV7hgd0fP2h3S7PYwOHiZgu2mfv+izRbsAjll4E6+ CzkRMNRVj4oLgW5b6qAthLYElmyOFLhqv9R2ng+lb+HhcCl4TBhA== X-Gm-Gg: AeBDiesFEewR19D8ITj6YpEIzqsB9eUp/qarig3VdABVgN2rxxjO28riaqnQJ4U4m1C /hz2FS9xbVj7f82uMTKebP9qdoqkCY9O1AwV16wzcATwVavYkgi3WhvAtLOePBUipSYlUX2adlR JR1eOygTG81Fsdac+5cC44hkmtBCxTr+P74pR+U3zM/vVdVnAQLYp6OUlKUaQaQ9+xWlgZOmgjS VPjd2Z0Bdbd4mLo32c/Hnu0+cnc7bl9lYhkovArTEIzdROaF3yQghrtute49znd1Zt8uIhxAEnV q1VwqvRGiLO/0RZDV9cpgvqGA8lUFGYYwCoIZThfBCsOT/NWLrW/SHHQIa/ptpRfv9lIqEc3u3/ T1i8hod7lcO/EV38NAJqHz0geZecD45zjoVfD/M2R06mdv99l1iUeFA1edb+BMZSwIyxwwVB8uV EWa1brL85v0VRlV7cZ0nOUr1zHToCefsGjz7I= X-Received: by 2002:a5d:584a:0:b0:43d:6a0c:9571 with SMTP id ffacd0b85a97d-44bb4af8960mr11709806f8f.11.1777839430893; Sun, 03 May 2026 13:17:10 -0700 (PDT) X-Received: by 2002:a5d:584a:0:b0:43d:6a0c:9571 with SMTP id ffacd0b85a97d-44bb4af8960mr11709777f8f.11.1777839430424; Sun, 03 May 2026 13:17:10 -0700 (PDT) Received: from [192.168.10.48] ([151.49.85.67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-44a98b76fd0sm21881053f8f.35.2026.05.03.13.17.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2026 13:17:08 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: chenyi.qiang@intel.com, Sean Christopherson Subject: [PATCH 2/2] KVM: x86: Fix misleading variable names and add more comments for PIR=>IRR flow Date: Sun, 3 May 2026 22:17:03 +0200 Message-ID: <20260503201703.108231-3-pbonzini@redhat.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260503201703.108231-1-pbonzini@redhat.com> References: <20260503201703.108231-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Rename kvm_apic_update_irr()'s "irr_updated" and vmx_sync_pir_to_irr()'s "got_posted_interrupt" to a more accurate "max_irr_is_from_pir", as neither "irr_updated" nor "got_posted_interrupt" is accurate. __kvm_apic_update_irr() and thus kvm_apic_update_irr() specifically return true if and only if the highest priority IRQ, i.e. max_irr, is a "new" pending IRQ from the PIR. I.e. it's possible for the IRR to be updated, i.e. for a posted IRQ to be "got", *without* the APIs returning true. Expand vmx_sync_pir_to_irr()'s comment to explain why it's necessary to set KVM_REQ_EVENT only if a "new" IRQ was found, and to explain why it's safe to do so only if a new IRQ is also the highest priority pending IRQ. No functional change intended. Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini --- arch/x86/kvm/lapic.c | 16 ++++++++-------- arch/x86/kvm/vmx/vmx.c | 40 ++++++++++++++++++++++++++++++++-------- 2 files changed, 40 insertions(+), 16 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 5ee14d6bc288..4078e624ca66 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -667,14 +667,14 @@ bool __kvm_apic_update_irr(unsigned long *pir, void *= regs, int *max_irr) u32 *__pir =3D (void *)pir_vals; u32 i, vec; u32 irr_val, prev_irr_val; - int max_updated_irr; + int max_new_irr; =20 if (!pi_harvest_pir(pir, pir_vals)) { *max_irr =3D apic_find_highest_vector(regs + APIC_IRR); return false; } =20 - max_updated_irr =3D -1; + max_new_irr =3D -1; *max_irr =3D -1; =20 for (i =3D vec =3D 0; i <=3D 7; i++, vec +=3D 32) { @@ -690,25 +690,25 @@ bool __kvm_apic_update_irr(unsigned long *pir, void *= regs, int *max_irr) !try_cmpxchg(p_irr, &prev_irr_val, irr_val)); =20 if (prev_irr_val !=3D irr_val) - max_updated_irr =3D __fls(irr_val ^ prev_irr_val) + vec; + max_new_irr =3D __fls(irr_val ^ prev_irr_val) + vec; } if (irr_val) *max_irr =3D __fls(irr_val) + vec; } =20 - return ((max_updated_irr !=3D -1) && - (max_updated_irr =3D=3D *max_irr)); + return max_new_irr !=3D -1 && max_new_irr =3D=3D *max_irr; } EXPORT_SYMBOL_FOR_KVM_INTERNAL(__kvm_apic_update_irr); =20 bool kvm_apic_update_irr(struct kvm_vcpu *vcpu, unsigned long *pir, int *m= ax_irr) { struct kvm_lapic *apic =3D vcpu->arch.apic; - bool irr_updated =3D __kvm_apic_update_irr(pir, apic->regs, max_irr); + bool max_irr_is_from_pir; =20 - if (unlikely(!apic->apicv_active && irr_updated)) + max_irr_is_from_pir =3D __kvm_apic_update_irr(pir, apic->regs, max_irr); + if (unlikely(!apic->apicv_active && max_irr_is_from_pir)) apic->irr_pending =3D true; - return irr_updated; + return max_irr_is_from_pir; } EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_apic_update_irr); =20 diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index a29896a9ef14..4e1aadd89c63 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7029,8 +7029,8 @@ static void vmx_set_rvi(int vector) int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu) { struct vcpu_vt *vt =3D to_vt(vcpu); + bool max_irr_is_from_pir; int max_irr; - bool got_posted_interrupt; =20 if (KVM_BUG_ON(!enable_apicv, vcpu->kvm)) return -EIO; @@ -7042,17 +7042,22 @@ int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu) * But on x86 this is just a compiler barrier anyway. */ smp_mb__after_atomic(); - got_posted_interrupt =3D - kvm_apic_update_irr(vcpu, vt->pi_desc.pir, &max_irr); + max_irr_is_from_pir =3D kvm_apic_update_irr(vcpu, vt->pi_desc.pir, + &max_irr); } else { max_irr =3D kvm_lapic_find_highest_irr(vcpu); - got_posted_interrupt =3D false; + max_irr_is_from_pir =3D false; } =20 /* - * Newly recognized interrupts are injected via either virtual interrupt - * delivery (RVI) or KVM_REQ_EVENT. Virtual interrupt delivery is - * disabled in two cases: + * If APICv is enabled and L2 is not active, then update the Requesting + * Virtual Interrupt (RVI) portion of vmcs01.GUEST_INTR_STATUS with the + * highest priority IRR to deliver the IRQ via Virtual Interrupt + * Delivery. Note, this is required even if the highest priority IRQ + * was already pending in the IRR, as RVI isn't update in lockstep with + * the IRR (unlike apic->irr_pending). + * + * For the cases where Virtual Interrupt Delivery can't be used: * * 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 @@ -7063,10 +7068,29 @@ int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu) * 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. + * + * In both cases, set KVM_REQ_EVENT if and only if the highest priority + * pending IRQ came from the PIR, as setting KVM_REQ_EVENT if any IRQ + * is pending may put the vCPU into an infinite loop, e.g. if the IRQ + * is blocked, then it will stay pending until an IRQ window is opened. + * + * Note! It's possible that one or more IRQs were moved from the PIR + * to the IRR _without_ max_irr_is_from_pir being true! I.e. if there + * was a higher priority IRQ already pending in the IRR. Not setting + * KVM_REQ_EVENT in this case is intentional and safe. If APICv is + * inactive, or L2 is running with exit-on-interrupt off (in vmcs12), + * i.e. without nested virtual interrupt delivery, then there's no need + * to request an IRQ window as the lower priority IRQ only needs to be + * delivered when the higher priority IRQ is dismissed from the ISR, + * i.e. on the next EOI, and EOIs are always intercepted if APICv is + * disabled or if L2 is running without nested VID. If L2 is running + * exit-on-interrupt on (in vmcs12), then the higher priority IRQ will + * trigger a nested VM-Exit, at which point KVM will re-evaluate L1's + * pending IRQs. */ if (!is_guest_mode(vcpu) && kvm_vcpu_apicv_active(vcpu)) vmx_set_rvi(max_irr); - else if (got_posted_interrupt) + else if (max_irr_is_from_pir) kvm_make_request(KVM_REQ_EVENT, vcpu); =20 return max_irr; --=20 2.54.0