Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp58123rwd; Wed, 24 May 2023 14:07:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4o1QRrCT1kC0Zv8qP6PHe0nPgWDxaxKmbxs+qEigiOZcVuERe1h5SPA4VDcwubiyjpHYkl X-Received: by 2002:a05:6a00:2352:b0:64f:40bc:74f3 with SMTP id j18-20020a056a00235200b0064f40bc74f3mr5065430pfj.13.1684962456858; Wed, 24 May 2023 14:07:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684962456; cv=none; d=google.com; s=arc-20160816; b=DErOzXAioar6E5zNXUk/plk6JUOuXPv7CEPVinRBY9cdpbBay65pfhABXyKV71+pN2 GmqEYONS0x6Hc6KCrpuLdIyQT/2suk2hq+u1D0yHMXADaujgFsflyGMgomtuCkg1XqG8 1VGXKQs11uK2mZiVCHYPz4c1Zw8ZG8FDeaPpTTbmxgYIOWeRxhMe6zQlxERKro6/PC5G pdmd9FfQ0uYBicHzrevqmhMhKp77/dYjo0XjQuQH2K67dLrfjgYa3DD1YPIfaRNrHyir RVkLPXpJtp54k3GkmdcYtkgZeCEdP4iIb4qWRnzAFCTZzCu8M3spDs1nrYx81406wp7u 827g== 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:dkim-signature; bh=zdskpbDr/vx+kwVgwoZ+l+PjPD1AoALpdTOdIckr/8Q=; b=eUp5imVu/aDowHdfGw8V8MLVsk0yz9ZA3H1e7hRZz/bEJ4mMevJF+6cmBfWC5eeA3R h81NmfTD7vvXd7X113113NB1Rhv3aEWyslknra6V7hVB91UkyOnDmGLZmgUQP4dWK7/d Gxly1IApKwiH8h2OhWtdmmX4GO7Bbh2umSoksXAZ3m16CgMgm9mj34DZznxULL9Hq9e8 syvosieDLw+BBvggi+XOW2/OA6hxKpaxjtxxwzMlW8Lsu7+12c3JiznLs+JwXa+J9Cf7 Ly3VGqOodN0XghwnsAuQGcTmM/UrY7VxekjSHuD15+a53uN2ecdVq2H3Wz4pkzxCYrV/ aZCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=BxaL6YiF; 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 b2-20020aa78ec2000000b00643b7b6bf0esi3691549pfr.261.2023.05.24.14.07.10; Wed, 24 May 2023 14:07:36 -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=20221208 header.b=BxaL6YiF; 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 S232281AbjEXVDt (ORCPT + 99 others); Wed, 24 May 2023 17:03:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229682AbjEXVDs (ORCPT ); Wed, 24 May 2023 17:03:48 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4884B3 for ; Wed, 24 May 2023 14:03:46 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id 98e67ed59e1d1-2533d8f48b5so393059a91.0 for ; Wed, 24 May 2023 14:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684962226; x=1687554226; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=zdskpbDr/vx+kwVgwoZ+l+PjPD1AoALpdTOdIckr/8Q=; b=BxaL6YiFs9lyGj44/uXDyTbkm9+MG2sne0WgHhR7Pu+EhZCcs8IH6vd6OsXjFjCyK8 2BGKd7iXWtQI+c6m6RVTqbmTstgL+aw0g0YY3uNb4ZCq3Wu7VuGy2b3wzwW4ZbOE8d8i qDeGYuF+SiMqMt2KVZrD8aPzBvbtG3dV3j4gIiOVmrc9CcseUpE9BvDdFKpR08c2bkWN XaQez5YABiG9AKStAj2frm/V2gPwZFHdRcQjlBO5L9BSMZLoEP7oTs12hYnCq/z+ZIE+ V8EJhZBYqhQXf/rUrY608YxfMU5fFowzLITDwZ0EOnmozO/kBGP+xDNEI9D+hRvNxQVO ARjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684962226; x=1687554226; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zdskpbDr/vx+kwVgwoZ+l+PjPD1AoALpdTOdIckr/8Q=; b=TxirdcU+nHFxZayO/+k6xiJmpT2s3Jn1LgQ93h5AvivffD5tEwQGQt3c1ld+c5Dz1q P5H0rR3F/QB0btAxneeL2IoOkbQmM41AT9MdFxWiSZp8yry76m85AWY/yuFO1P2cRjPT W3Q81wIv9DZqwhxeDAKJdeEXXPZAAVKa7lucJl1OP4DOFCgfZ32/VTuvrQhMckv6ops9 gBtfwjL0DeeNoQ5WXd+dM7ZUEIzs3I7Ylr2JRXcco8ZiZSP88VtVA3QKeRUbHSLuNKtU dIo7JB6qdcTI5C2MdPGEe3osg5qPTko3fbqVeKv7Jhvv6jV+aNMMj+Nu9qZmj7GU1RiJ ScCQ== X-Gm-Message-State: AC+VfDycVTCmYLVU77kMZuVrZT+J9NW7PnlfOOINR8z1TUsAksAnbDKP YVty7MfTrqm//sYlV1RYRAVS7GyGv0Y= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:840c:b0:250:a6c1:b843 with SMTP id j12-20020a17090a840c00b00250a6c1b843mr4449282pjn.9.1684962226351; Wed, 24 May 2023 14:03:46 -0700 (PDT) Date: Wed, 24 May 2023 14:03:44 -0700 In-Reply-To: <20230310105346.12302-4-likexu@tencent.com> Mime-Version: 1.0 References: <20230310105346.12302-1-likexu@tencent.com> <20230310105346.12302-4-likexu@tencent.com> Message-ID: Subject: Re: [PATCH 3/5] KVM: x86/pmu: Move the overflow of a normal counter out of PMI context From: Sean Christopherson To: Like Xu Cc: Paolo Bonzini , Ravi Bangoria , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" 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=unavailable 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 On Fri, Mar 10, 2023, Like Xu wrote: > From: Like Xu > > >From the guest's point of view, vPMU's global_status bit update following > a counter overflow is completely independent of whether it is emulated > in the host PMI context. The guest counter overflow emulation only depends > on whether pmc->counter has an overflow or not. Plus the counter overflow > generated by the emulation instruction has been delayed and not been > handled in the PMI context. This part of the logic can be unified by > reusing pmc->prev_counter for a normal counter. I've asked many times. Please write changelogs that state what the patch actually does, not what "can" be done. The other patches in this series have similar problems, e.g. desribe the state _after_ the patch is applied, not what the patch does. IIUC, this is effectively deferring injection to kvm_pmu_handle_event() and kvm_pmu_handle_pmc_overflow(). The changelog says nothing of the sort though. > However for a PEBS counter, its buffer overflow irq still requires hardware to > trigger PMI. I didn't follow this. Hardware isn't triggering the PMI the guest sees, that's still coming from KVM. Are you saying that KVM doesn't have a way to detect overflow for PEBS counters, i.e. would drop the PMI as the hardware PMI is the only notification KVM gets?