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 4720FC77B73 for ; Wed, 24 May 2023 21:03:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233242AbjEXVDu (ORCPT ); Wed, 24 May 2023 17:03:50 -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-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: 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?