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 4723CC433F5 for ; Tue, 11 Jan 2022 00:57:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346038AbiAKA5M (ORCPT ); Mon, 10 Jan 2022 19:57:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229701AbiAKA5I (ORCPT ); Mon, 10 Jan 2022 19:57:08 -0500 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 997B5C061748 for ; Mon, 10 Jan 2022 16:57:08 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id h1so14701358pls.11 for ; Mon, 10 Jan 2022 16:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=U+Wx73GN18nvNIxW83NvEPo0/N8UDKXuIJQiQCJDnlQ=; b=W3uF1D/1TcPvfyCWEuQlCC/ZfqmxcCgVeUkXDF2tP0gUnoSZjf5vsm4z4RnSaC+VzG 9mCRsKcXyQ9qqbaEeyon8nAdKJkcbgXfLWa/My5hClQZV9DSLea+6U+mBDwA7aHFto01 kM/r6zJGX6DuGWYWcWGAUzJpBlpMSvRLSkwB/+o5VoxYqjFEZjq0fCuFFENKnlM2P3Or oYZuf+4C5kuyIchn2HnbVjzxEgKkcXvlBYS6mzR9pohNotyLnPk/UKOvtqOyQOrmwbkB JK7Jqul1MzLKItoxcEV28I22HO0VzyQ8iioEmV718/b+11ZrLMslwNCchDjygZeUZGp1 FS1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U+Wx73GN18nvNIxW83NvEPo0/N8UDKXuIJQiQCJDnlQ=; b=e6zEX5HD1atYeDCpzkoxJkJ5N1u9bI8F+trrQWulg1dl1RZE92VeRBkwskDgm16v0W OkkSgXKkuHkMnMjzWpL+etGT0PhW2fnEvLkN+WAiPtXoz9+rkyswGdjnC07Y9wpS8UPX eU7ZgnIeS2+M+HpD8OdH6xCvUuSvDbIM9Jqfq5FnRBkRGH38GJ2Kqgg7U9LRteZUcElI 5p5QJnmGbPG0hOa+rtbTYCZ5TaxEHpN+lF+F1wIrFoTlaTdRmYPzAdfxgGL+wkY6G3wq ScJY2C997aDkv+BNXXE65XZzarndcREZdtVQh34G7KCueVpZfU7C1MKqrPDgENGzvYVR 7Hqw== X-Gm-Message-State: AOAM53090U9XB3YZXkSbw6b+z1iaRPxt95K0Rg8iJwjVFiiLRgLd7ofY PIdsqKq8w6Bho/OsEGlDyfak0g== X-Google-Smtp-Source: ABdhPJyaxEHTTqdck5k/nSmI+nCln5IHFkOM+cvXjeodmuDO+C5RFav2V+9vgqFil9ytGRtHWnCdlg== X-Received: by 2002:a63:68c6:: with SMTP id d189mr2056686pgc.32.1641862627949; Mon, 10 Jan 2022 16:57:07 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id mq12sm218893pjb.48.2022.01.10.16.57.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 16:57:07 -0800 (PST) Date: Tue, 11 Jan 2022 00:57:03 +0000 From: Sean Christopherson To: Like Xu Cc: Paolo Bonzini , Jim Mattson , Wanpeng Li , Vitaly Kuznetsov , Joerg Roedel , x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] KVM: x86/pt: Ignore all unknown Intel PT capabilities Message-ID: References: <20220110034747.30498-1-likexu@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220110034747.30498-1-likexu@tencent.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Jan 10, 2022, Like Xu wrote: > From: Like Xu > > Some of the new Intel PT capabilities (e.g. SDM Vol3, 32.2.4 Event > Tracing, it exposes details about the asynchronous events, when they are > generated, and when their corresponding software event handler completes > execution) cannot be safely and fully emulated by the KVM, especially > emulating the simultaneous writing of guest PT packets generated by > the KVM to the guest PT buffer. > > For KVM, it's better to advertise currently supported features based on > the "static struct pt_cap_desc" implemented in the host PT driver and > ignore _all_ unknown features before they have been investigated one by > one and supported in a safe manner, leaving the rest as system-wide-only > tracing capabilities. > > Suggested-by: Paolo Bonzini > Signed-off-by: Like Xu > --- > v1 -> v2 Changelog: > - Be safe and ignore _all_ unknown capabilities. (Paolo) > > Previous: > https://lore.kernel.org/kvm/20220106085533.84356-1-likexu@tencent.com/ > > arch/x86/kvm/cpuid.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 0b920e12bb6d..439b93359848 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -901,6 +901,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) > break; > } > > + /* It's better to be safe and ignore _all_ unknown capabilities. */ No need to justify why unknown capabilities are hidden as that's very much (supposed to be) standard KVM behavior. > + entry->ebx &= GENMASK(5, 0); Please add a #define somewhere so that this is self-documenting, e.g. see KVM_SUPPORTED_XCR0. And why just EBX? ECX appears to enumerate features too, and EDX is presumably reserved to enumerate yet more features when EBX/ECX run out of bits. And is there any possibility of a malicious user/guest using features to cause problems in the host? I.e. does KVM need to enforce that the guest can't enable any unsupported features? > for (i = 1, max_idx = entry->eax; i <= max_idx; ++i) { > if (!do_host_cpuid(array, function, i)) > goto out; > -- > 2.33.1 >