Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp437221rwb; Fri, 2 Sep 2022 17:26:16 -0700 (PDT) X-Google-Smtp-Source: AA6agR4D8k11EG+50uIMXy4HK3UWRnYRpv0pouNdeW3mo38yTEjeNfFacxwyfvH0rYF2Qp3Nf5QC X-Received: by 2002:a17:907:3e12:b0:741:66c4:5658 with SMTP id hp18-20020a1709073e1200b0074166c45658mr20674236ejc.486.1662164776656; Fri, 02 Sep 2022 17:26:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662164776; cv=none; d=google.com; s=arc-20160816; b=DwWv3WiKKGDoHlkKnykaycSWPM7Yhr6Ez44gPxE+MUseKTBo11M0QUs2RPV9UNPMeV L3R+QQdBTfU44v/yH3ISXPbsIXl4NtwYCzt2JVJzau/k/bwhyr3d9WPenWhQux4y6B9c fT83uylZY8wT4VDDKb6cQg4LYZsyRWJ4bTIeqqY6i90x5gSTEzrOF+M3sXJjyVW7ZIoW pta9q8Y/6vu2TbD8P/Ox3At1rbr4Ru+ZDr4Kn91FVuY0rguDZCXmf+8eL7eMr1OEIXBY ijrnv9pp0Y1i0Il0XYCeBuPbLZdm7CHMS9mrBlrkFss6gYU63pF8SVBPW1MUc3dG3cg3 ilNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:reply-to:dkim-signature; bh=tz9XFzkzR4iwpvliIXrKjfw6rH6NLo3IRqdjhrYMVRc=; b=NqRAVhIHBuV09zDRQ7ojkaZMJifSaXxqXGJQaiHb8V/sNYm8uk/dQg0u72b2i7gp5f 12cqf1FuO9wVKV7s+7hAYRouBrpf7Ey9kdtRTDqgOgSUa9NrLwR5lKKZ5HhqwuxE1pde +OriMK6WUzyKI5urAwIw0WMNlozYN6wBw38Hgng3w5zA8b7CRKJAbRIEgMIx/om2BHn5 ckxNFqIk5MYnLmA+1v+x0j4If1Va3IYn8RY2GJkmUaMetegFLzKyJDbZpXtoKDH5rar7 1m0Q4B8SBYUKPsBHJUFlec7TqJGwx6rhPvD5TJu0f415IzuaaaNLFnYi0Vcfw04yS4Pl SB7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=MqzieyIB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u14-20020a170906b10e00b007414e669eefsi2647589ejy.439.2022.09.02.17.25.50; Fri, 02 Sep 2022 17:26:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=MqzieyIB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231712AbiICAX4 (ORCPT + 99 others); Fri, 2 Sep 2022 20:23:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230173AbiICAXV (ORCPT ); Fri, 2 Sep 2022 20:23:21 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7930EF63DB for ; Fri, 2 Sep 2022 17:23:20 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id i3-20020aa78b43000000b005320ac5b724so1729467pfd.4 for ; Fri, 02 Sep 2022 17:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date; bh=tz9XFzkzR4iwpvliIXrKjfw6rH6NLo3IRqdjhrYMVRc=; b=MqzieyIBuWuV6MtJvV/l2VvfU+bUyxxlAB2jXhMmb/8OEXHE/+kj8t6rUnbRsdk9ri opzJegfNiPb9BGkxITrQtthYkI4vRiNauhc3IG9/xIrOjzpOMvnMUh4eLdEdNuo/nPAo oWY9pbgskw8qGdSx09c1oYF41O8eM7zxMj/rlIkZ7w0Hp5hy/fmuqGUAVpmy/GYYIheP lFWIP7OXA4391vxIrc0fjwpgX9Q3EULXweFcWP5+okZRt1oyHAtVNmfpINqfxMn4+mO9 dPEK44vkBrdGE9Q2CQ4AZ/58vBkzhq+za1dpNwuQ6W6QEwtQ2DpIIVJSITzjPssGZK52 eW/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date; bh=tz9XFzkzR4iwpvliIXrKjfw6rH6NLo3IRqdjhrYMVRc=; b=B7E2Wrrk+i+YBLfBkz2FJaWgUyLo3CqhVfKjqy8+qpuyB+ZyrVtUO5r2S3g2AZ9PZv NtjtUY5r3esBvUTwASJnwzR0kBjQQmnYdS4l8XcO9kTxEfIVKYBcQVbnFKYw9+hHk+C0 a843eaFrRSOZ93wB9B95SmunsXtWFNOV29i8KECOAsHVxh8t0K3NOUYsWVwFMeLTbkF8 N5YbTEZrlmX6PW7GxvHDpxaodpwTIJere+y0hw4gUP4raCfx5zk1JFlES55O7jcra3fG R0Q1dxvslpVbJLz9T2KXOKs2ZEtLf2dXMwAXdpvSX5jhThAX6ABpMCOD2lu5WhJ658Ep XeVg== X-Gm-Message-State: ACgBeo2vuw4+GI2NUf1VhInFytWf+2DJ1ymGhs8a2jmu4kSa3ZFQ2ytk pLxTq8DTB52DeSM2L+Yj6PUamm5j8cM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:d150:b0:1fd:9336:5db3 with SMTP id t16-20020a17090ad15000b001fd93365db3mr7469743pjw.242.1662164600066; Fri, 02 Sep 2022 17:23:20 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 3 Sep 2022 00:22:43 +0000 In-Reply-To: <20220903002254.2411750-1-seanjc@google.com> Mime-Version: 1.0 References: <20220903002254.2411750-1-seanjc@google.com> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220903002254.2411750-13-seanjc@google.com> Subject: [PATCH v2 12/23] KVM: x86: Disable APIC logical map if logical ID covers multiple MDAs From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Suravee Suthikulpanit , Maxim Levitsky , Li RongQing Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Disable the optimized APIC logical map if a logical ID covers multiple MDAs, i.e. if a vCPU has multiple bits set in its ID. In logical mode, events match if "ID & MDA != 0", i.e. creating an entry for only the first bit can cause interrupts to be missed. Note, creating an entry for every bit is also wrong as KVM would generate IPIs for every matching bit. It would be possible to teach KVM to play nice with this edge case, but it is very much an edge case and probably not used in any real world OS, i.e. it's not worth optimizing. Use an impossible value for the "mode" to effectively designate that it's disabled. Don't bother adding a dedicated "invalid" value, the mode handling will be cleaned up in the future and it would take just as much effort to explain what value is "safe" at this time. Fixes: 1e08ec4a130e ("KVM: optimize apic interrupt delivery") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/lapic.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index d956cd37908e..6b2f538b8fd0 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -300,8 +300,15 @@ void kvm_recalculate_apic_map(struct kvm *kvm) if (!kvm_apic_map_get_logical_dest(new, ldr, &cluster, &mask)) continue; - if (mask) - cluster[ffs(mask) - 1] = apic; + if (!mask) + continue; + + if (!is_power_of_2(mask)) { + new->mode = KVM_APIC_MODE_XAPIC_FLAT | + KVM_APIC_MODE_XAPIC_CLUSTER; + continue; + } + cluster[ffs(mask) - 1] = apic; } out: old = rcu_dereference_protected(kvm->arch.apic_map, -- 2.37.2.789.g6183377224-goog