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 C92D1C433EF for ; Mon, 23 May 2022 15:56:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238336AbiEWP4M (ORCPT ); Mon, 23 May 2022 11:56:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238282AbiEWPz6 (ORCPT ); Mon, 23 May 2022 11:55:58 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E87652B2A; Mon, 23 May 2022 08:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653321356; x=1684857356; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=/SvgtnbrTcyFxT3V8Yw8Zvk25pwqcKM3FaWkynyJDfQ=; b=WlxGJpYnCeBl+dxVHJKGBLGDwlKl3ZaHHChNLggdUchh1pMZn1EwgmYI 6MOvMeetGjjiumYPSCBVN4iY6Ppo8QWW2tHtmqtp5f/A9KdBM4hGDLbWV BCcvg7bSFO/eviJsbhtP+gbLeocwqSvsW4Jr+lIFINNQs1FC928RNr9Qb k9pHrfI/TfRLJZnWi/pfIu93LO+fSbzLc12MfI6hj8WdjVdEknhiSNdzZ 5EXtB5RxVTvcQrm6PuIEqUp2XNbQKoLRyKt7YpLU3j1n+RHVbCenkU5Mi ZLB90pcmzdN0WmOURHe3qgpKppVvsIpRccI55Lte6S4AS4oicEApxqhbS g==; X-IronPort-AV: E=McAfee;i="6400,9594,10356"; a="359657217" X-IronPort-AV: E=Sophos;i="5.91,246,1647327600"; d="scan'208";a="359657217" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 May 2022 08:54:51 -0700 X-IronPort-AV: E=Sophos;i="5.91,246,1647327600"; d="scan'208";a="600718969" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.116.169]) ([10.209.116.169]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 May 2022 08:54:51 -0700 Message-ID: <2ff19ce9-98e3-7867-9762-ffae049f1d9b@linux.intel.com> Date: Mon, 23 May 2022 08:54:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH V2 5/6] perf kvm report: Add guest_code support Content-Language: en-US To: Adrian Hunter , Arnaldo Carvalho de Melo Cc: Jiri Olsa , Namhyung Kim , Ian Rogers , Leo Yan , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, kvm@vger.kernel.org References: <20220517131011.6117-1-adrian.hunter@intel.com> <20220517131011.6117-6-adrian.hunter@intel.com> From: Andi Kleen In-Reply-To: <20220517131011.6117-6-adrian.hunter@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/17/2022 6:10 AM, Adrian Hunter wrote: > Add an option to indicate that guest code can be found in the hypervisor > process Sorry for harping on this, but is it correct that this assumes that the code is still at the original location at decode time? If yes we need some warnings for this, something like: This only works when the code is still available in the riginal memory location at decode time. This is typically the case for kernel code (unless modules are unloaded). For user programs it only works as long as there is no memory pressure which might cause the memory to be reused. For dynamically generated (JITed) code it might be rather unreliable unless the hypervisor is SIGSTOPed during decoding.