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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16DE0CDD0FF for ; Tue, 22 Oct 2024 22:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To:From: Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XOqBWZrZXtWTTpPGYoMu4m/4ZnTX0L7qg4xRYMuF1qk=; b=cW8tDIuwYPa1N6NjcmMlLSf9XK 0r19foKL+rdUxI+kUqzyrAMSifw40wG5ZW5GAhyeiu+uIAIe3EW5MoLsaRbA++V0jf210rrUzODtJ 3B/LaCDIyIb4QjI4WxhQbpoRRAHdvVU4dHsRxAgve0wuI4y4XBr0+aJe1uU3Q09Fgzk6XFJGxXwnk 6kpVOdqvnsZWANFICCdEO0S2LfbM9PwQkIyWqJTIsG9KAwiN4Bmj/OfVcHKf9D0ZMW2gqBTUfOHtd qvm5zaNsX14vlLWix1M3+yqwGUPJu7vUHVShY/yLTMVazKN7ctDgo/qlLz07DXWZk5tU+/pED5l4V CMrzaMkw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3NQb-0000000CLoS-02Iz; Tue, 22 Oct 2024 22:32:37 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t3NP3-0000000CLW0-0m7g for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 22:31:02 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-6e3204db795so92229107b3.2 for ; Tue, 22 Oct 2024 15:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729636259; x=1730241059; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=XOqBWZrZXtWTTpPGYoMu4m/4ZnTX0L7qg4xRYMuF1qk=; b=mQ9TmZrhAIeNv+Jn/5KPfWa2jqdUSEo2cbvzc13oBamiZbaGSL7DBm/0vkdcwBxot5 4HHbaYrBFZaLQeZ8uIbbdpl5iwRMRX+7pFN8bwy2kBh2otyimjPUrq9u4mvQgb/jrJed yOALKMaClpIy/MWtDDN95RpZoYfrQHL3ZD6RGwxcYtfqowPYH4VyehoCIs7/j6omVHUN PH828FdEHsJF7+HUTrjHDlAue5P3bLr1lqKw8kXFYIwqvXZpuJpiPuEs6MLXFIEH7GYa OEhxx4lHMKsbLXYzhB9hq8OB7nwr6/Ga47mBqH/rTSo7GfNCzGS19vbnxR7sIYsypL2X Jgiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729636259; x=1730241059; 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=XOqBWZrZXtWTTpPGYoMu4m/4ZnTX0L7qg4xRYMuF1qk=; b=k42yTWmk1yV8YZPhkNcz0Q8+VhEmEwtd8cjOzE4gur08ufYW4h8z9uBNocznRsC0Nr hSWk4yMF0tx8ZnorOVco0NerMR8hU+7DAGYbg5H1egXXuWcwtLEY8c+3IdRbl9NZWFa9 hPgHcRtV1KgDTnq2/DzOdmW6ePhQ3Lq3FbTs2FwP/jIHEaeRLyUAQbZhEtXZ1nLFfXkN ix+DErJoJu9VZ+k0U4n1sXk4KoBeVIuh+tvuQstSUBmJY7xqACkaacQGiqti8e32kUgd 1JaAC3HePeukh8Xruc+b+U8EJlI6BLkKo34ZnPn7smyW9LzMAA3YX56El+JYjiHfw6wx +afg== X-Forwarded-Encrypted: i=1; AJvYcCX8NfQOmLHa57FD5P4LmdIJlVZseu6sOC9zM15u4oXTqhkcozHOiOSFa7aNGhqcuiPX4SZ9yndJPW15pCnNJKWS@lists.infradead.org X-Gm-Message-State: AOJu0YwGIUhixI/NL/QvIjDFwGvLy3AXT2ZtEwcybYOLwaoyfyvHg520 /ON66yIoDAq7siUkgRnW6/J+JfW7HKWRV4AWuTvp+i3moWq3eEzjEeqLEvrz6N2a2bZ0KiH9mR1 Zxw== X-Google-Smtp-Source: AGHT+IGcqbY82rYWFSyzU4sD78yuqoJ/yG31UhWaIGXmch+HUW0FApvVNi4wRoSd0uA0A0VOd4tLZ9MP+V4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a05:690c:6485:b0:6e3:da91:3e17 with SMTP id 00721157ae682-6e7f0db3b18mr232037b3.2.1729636259303; Tue, 22 Oct 2024 15:30:59 -0700 (PDT) Date: Tue, 22 Oct 2024 15:30:57 -0700 In-Reply-To: <2a8e6f2c-4284-4218-9b91-af6a4d65e982@intel.com> Mime-Version: 1.0 References: <20241014105124.24473-1-adrian.hunter@intel.com> <20241014105124.24473-4-adrian.hunter@intel.com> <2a8e6f2c-4284-4218-9b91-af6a4d65e982@intel.com> Message-ID: Subject: Re: [PATCH V13 03/14] KVM: x86: Fix Intel PT Host/Guest mode when host tracing also From: Sean Christopherson To: Adrian Hunter Cc: Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Mark Rutland , Alexander Shishkin , Heiko Carstens , Thomas Richter , Hendrik Brueckner , Suzuki K Poulose , Mike Leach , James Clark , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, Yicong Yang , Jonathan Cameron , Will Deacon , Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , Ian Rogers , Andi Kleen , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, H Peter Anvin , Kan Liang , Zhenyu Wang , mizhang@google.com, kvm@vger.kernel.org, Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241022_153101_436919_58DA7312 X-CRM114-Status: GOOD ( 35.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 22, 2024, Adrian Hunter wrote: > On 22/10/24 19:30, Sean Christopherson wrote: > >>> LOL, yeah, this needs to be burned with fire. It's wildly broken. So for stable@, > >> > >> It doesn't seem wildly broken. Just the VMM passing invalid CPUID > >> and KVM not validating it. > > > > Heh, I agree with "just", but unfortunately "just ... not validating" a large > > swath of userspace inputs is pretty widly broken. More importantly, it's not > > easy to fix. E.g. KVM could require the inputs to exactly match hardware, but > > that creates an ABI that I'm not entirely sure is desirable in the long term. > > Although the CPUID ABI does not really change. KVM does not support > emulating Intel PT, so accepting CPUID that the hardware cannot support > seems like a bit of a lie. But it's not all or nothing, e.g. KVM should support exposing fewer address ranges than are supported by hardware, so that the same virtual CPU model can be run on different generations of hardware. > Aren't there other features that KVM does not support if the hardware support > is not there? Many. But either features are one-off things without configurable properties, or KVM does the right thing (usually). E.g. nested virtualization heavily relies on hardware, and has a plethora of knobs, but KVM (usually) honors and validates the configuration provided by userspace. > To some degree, a testing and debugging feature does not have to be > available in 100% of cases because it can still be useful when it is > available. I don't disagree, but "works on my machine" is how KVM has gotten into so many messes with such features. I also don't necessarily disagree with supporting a very limited subset of use cases, but I want such support to come as well-defined package with proper guard rails, docs, and ideally tests. > >>> I'll post a patch to hide the module param if CONFIG_BROKEN=n (and will omit > >>> stable@ for the previous patch). > >>> > >>> Going forward, if someone actually cares about virtualizing PT enough to want to > >>> fix KVM's mess, then they can put in the effort to fix all the bugs, write all > >>> the tests, and in general clean up the implementation to meet KVM's current > >>> standards. E.g. KVM usage of intel_pt_validate_cap() instead of KVM's guest CPUID > >>> and capabilities infrastructure needs to go. > >> > >> The problem below seems to be caused by not validating against the *host* > >> CPUID. KVM's CPUID information seems to be invalid. > > > > Yes. > > > >>> My vote is to queue the current code for removal, and revisit support after the > >>> mediated PMU has landed. Because I don't see any point in supporting Intel PT > >>> without a mediated PMU, as host/guest mode really only makes sense if the entire > >>> PMU is being handed over to the guest. > >> > >> Why? > > > > To simplify the implementation, and because I don't see how virtualizing Intel PT > > without also enabling the mediated PMU makes any sense. > > > > Conceptually, KVM's PT implementation is very, very similar to the mediated PMU. > > They both effectively give the guest control of hardware when the vCPU starts > > running, and take back control when the vCPU stops running. > > > > If KVM allows Intel PT without the mediated PMU, then KVM and perf have to support > > two separate implementations for the same model. If virtualizing Intel PT is > > allowed if and only if the mediated PMU is enabled, then .handle_intel_pt_intr() > > goes away. And on the flip side, it becomes super obvious that host usage of > > Intel PT needs to be mutually exclusive with the mediated PMU. > > And forgo being able to trace mediated passthough with Intel PT ;-) It can't work, generally. Anything that generates a ToPA PMI will go sideways. In the worst case scenario, the spurious PMI could crash the guest. And when the mediated PMU supports PEBS, that would likely break too.