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 8F4BFC77B7C for ; Wed, 24 May 2023 21:03:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230504AbjEXVDs (ORCPT ); Wed, 24 May 2023 17:03:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229482AbjEXVDr (ORCPT ); Wed, 24 May 2023 17:03:47 -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 D4A2FC1 for ; Wed, 24 May 2023 14:03:46 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id 98e67ed59e1d1-254b056a36dso389170a91.1 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=YbfKKLzlOdG7sIFDkzgMelBk37G6JF1o6gLH0MZ0NRCT1BrsXWvPcE/Kb+RSC665b0 T5oWZh5EqFj6lsb9QHxoQgJ4J8gq9kLa5pcGUsvv9FUXh/uN43nxgrcP7xtjNG8ILSuH SkWor+oIMDyAV5rKHg3kHZfUgJ9rqecm0h2TWMlQU5MfmM+T96olNSJ8oAOTxs4wGTnB cwJpEk/grJZTVKWZJCf+HRx/UsO2pFCgCsJv4iISWZ6gPtx9JweWFPbqZ8dAqcFQOs1u 8AJp7YZbG42lr6ES4RkEcH2i743GEg2KwUmsIVc8sVH3wGtwMxLwF2hfnaDeNu8tBWPh IYDQ== X-Gm-Message-State: AC+VfDyR/r7lq2NCeMGYPZyorRvuVeNydYn9ktta8Qcub+K6l9MrhbC9 zvNhhNvvH6PEUS9ZjsjRGJ71ENf74/I= X-Google-Smtp-Source: ACHHUZ4zaHeDuW0F2TVmtsoRzsaCxJ5RaaPMuhtuz7LQg9D2me9CV3N0a41C9/IXiDzFs2G86pxWKAUz5m0= 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" Precedence: bulk List-ID: X-Mailing-List: kvm@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?