From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80BCBC433EF for ; Tue, 12 Jul 2022 15:58:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232649AbiGLP6u (ORCPT ); Tue, 12 Jul 2022 11:58:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229862AbiGLP6q (ORCPT ); Tue, 12 Jul 2022 11:58:46 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A0C2A448 for ; Tue, 12 Jul 2022 08:58:43 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id v7so5771144pfb.0 for ; Tue, 12 Jul 2022 08:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3NuNGzPX7l2+4H4FqXMF3G2Iv4qIhgXKrczFI5RGpVE=; b=KobxG4F8v+qthtwpu7gbH2IQkDOCkXPPXTqHgHWNsvq6z38hgkKWUYINThYxJYBVjw evvB8xnHRoaczS8dHVfibY8iwBGTIYBP/5sj2W++9tP+LqoVuRSit+KlkFTWZYE14FGm C2r93ude/BoVRbzYL2mrDbdViI5aPXPl/pmDUdQgLowPuNBHh3cifa+dXlE4ddNA82J2 86z3wVU4x3sIlHFaUNkJCa7sM6UBMTldfXCp+PiGW1t/5M9Ym9LVF+k125IPnqHOZ3JQ eDJcyXznBLiNyIh6oVr53sd8I9Xh+dcoAN5clFw3PfNtUQAifbjMnu39wUAYk+FqbPb6 J8WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3NuNGzPX7l2+4H4FqXMF3G2Iv4qIhgXKrczFI5RGpVE=; b=VK9q2ztaMihXwYI+B8gzxgwi8bFlBrEG8tyDe/aOYvTs0aYFNLWfhaHhwdMP55iC24 aezKPi8jZEk3lsVCPRHaPv09hyWxCj9JRZf+FCsVVNwgpqdzdaizPKzvBp3CzlLnIPz4 YGziH9IaeIKfQp0OcRLP1gl5STmnByGcCBCC+sgey9eLkyqiZ7TBzOTCg1lFZxZxLcf1 QPYlEDAoHbLpT3GesURg+tBJC/ZjqWL1rL15qgfohHQCBjR5m8GnXbbvjggMMb74a7bH aGRakKpHSB7IZzMebHeJEpusoKq3jF23U/ZCxMeHjCfF5dBo5IQKGAS3uzGerFGL8Jqc Pb4A== X-Gm-Message-State: AJIora/uzbx7fAIlbG18O7copcnU63ujl3as4enM0DysmVkfZYFKX7en rkrKWQfdcolSL7/N47AjLBxgUw== X-Google-Smtp-Source: AGRyM1sxLANce1xqGhsht71y51IJWGaCzyWUoPHm08yJixijPHX2pu2nnl4Pm3GBexyPjWUZpfXJNg== X-Received: by 2002:a05:6a00:22d6:b0:52a:b9fc:4c88 with SMTP id f22-20020a056a0022d600b0052ab9fc4c88mr18633914pfj.3.1657641522504; Tue, 12 Jul 2022 08:58:42 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id w1-20020a1709026f0100b0016b953872a7sm6963581plk.201.2022.07.12.08.58.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 08:58:41 -0700 (PDT) Date: Tue, 12 Jul 2022 15:58:37 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: Wang Guangju , pbonzini@redhat.com, vkuznets@redhat.com, jmattson@google.com, wanpengli@tencent.com, bp@alien8.de, joro@8bytes.org, suravee.suthikulpanit@amd.com, hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, lirongqing@baidu.com Subject: Re: [PATCH v3] KVM: x86: Send EOI to SynIC vectors on accelerated EOI-induced VM-Exits Message-ID: References: <20220712123210.89-1-wangguangju@baidu.com> <6dcd11aefcd817ee0f8603328886df3023a98fa5.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6dcd11aefcd817ee0f8603328886df3023a98fa5.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 12, 2022, Maxim Levitsky wrote: > On Tue, 2022-07-12 at 20:32 +0800, Wang Guangju wrote: > > When EOI virtualization is performed on VMX, kvm_apic_set_eoi_accelerated() > > is called upon EXIT_REASON_EOI_INDUCED but unlike its non-accelerated > > apic_set_eoi() sibling, Hyper-V SINT vectors are left unhandled. > > > > Send EOI to Hyper-V SINT vectors when handling acclerated EOI-induced > > VM-Exits. KVM Hyper-V needs to handle the SINT EOI irrespective of whether > > the EOI is acclerated or not. > > How does this relate to the AutoEOI feature, and the fact that on AVIC, > it can't intercept EOI at all (*)? > > Best regards, > Maxim Levitsky > > > (*) AVIC does intercept EOI write but only for level triggered interrupts. If there are one or more AutoEOI vectors, KVM disables AVIC. Which begs the question of why SVM doesn't disable the AVIC if there's an edge-triggered I/O APIC interrupt that has a notifier, which is where kvm_hv_notify_acked_sint() eventually ends up. vmx_load_eoi_exitmap() sets the EOI intercept for all such vectors, and for _all_ SynIC vectors (see vcpu_load_eoi_exitmap()), but AFAICT SVM relies purely on the level-triggered behavior. KVM manually disables AVIC for PIT reinjection, which uses an ack notifier; AFAICT that's a one-off hack to workaround AVIC not playing nice with notifiers. So yeah, it seems like the proper fix would be to add svm_load_eoi_exitmap() and replace the PIT inhibit with a generic ACK inhibit that is set if there is at least one edge-triggered vector present in the eoi_exit_bitmap. Tangentially related to all of this, it's bizarre/confusing the KVM_CREATE_PIT{2} is allowed regardless of whether or not the I/O APIC is in-kernel. I don't see how it can possibly work since create_pit_timer() silently does nothing if the I/O APIC isn't in-kernel.