Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3443172pxb; Mon, 6 Sep 2021 22:42:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyV5Nr2FKx+sv7ay4dcrqR1saxW0JRqrlRdJQzrfv7IUsCvO0EVN8uvGSxknrLFCtkmvxqR X-Received: by 2002:a17:906:56cc:: with SMTP id an12mr16953744ejc.456.1630993377167; Mon, 06 Sep 2021 22:42:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630993377; cv=none; d=google.com; s=arc-20160816; b=CvKIwNHoyPcYOAW7pf/iIF/O5bkVrTHoY5vvHpd8wOFD/cQNt9ckJz1x904Dpaonqr McRg0iuLs1KtL6kxLV5akYEQ80/cxy0OjjLuy8Y30V+vSMb4fQMjP0tf+Uz0eeQQNUUY 3+EcM5Uzof3sqjcrIWhaPwI+I6aeeClL09Vb38a7Jyry12+/+2kQLXrAL5gJcpd7GL4s SjjUR1pz3JFhBo0ZfaTZ9OeGz1rRY5eHIJ8Bsnb3H8uOCWveexu0wYC6vdcwrXq8QPNF eDWNT9sl3Cwy4HPb+m9ObBYAiXmPRHw4Lte5XuVfC7u254t+3hTNiAqjBcm+6qjwNnhL WK8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6ZN+rMdFz6ojV+Xtu1UCBGcmXWV8vQeN+N4Miybyvws=; b=k0LGhr/0U26FpstiDwgqWfrEmazCFKZixq0m1LfGQ5xbvuOJdNhMALT2kbJ3PiQMuO w+dMPjzmjE/a2ZstKCTxfhlWimkRhPPzoh+IJKpVhonb2bVjw9Se4sPYeV/5nLFIsyl1 u7FtT9U4xNf4kb5Z6gsu35hhzz13c/ucc5MFJ8EiTAT2AOtElCp4J5s3fzkIW19PRWlu gwAhoVE8hMKT2r6aiVt2YGIxmA6ixPdI54rI1QQ8vopq375dYEQMCFS56Qd+4LBypiU1 7jFpIPsLY03NNyGghNY12xZbCpkkXKyTZ3sQUPxX4P87PBUgrixaEumsKKPMkrwJRJKq 6Clg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m24si10080755ejn.39.2021.09.06.22.42.33; Mon, 06 Sep 2021 22:42:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237639AbhIGFhz (ORCPT + 99 others); Tue, 7 Sep 2021 01:37:55 -0400 Received: from mga04.intel.com ([192.55.52.120]:25171 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230486AbhIGFhw (ORCPT ); Tue, 7 Sep 2021 01:37:52 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10099"; a="218240856" X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="218240856" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2021 22:36:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="430088006" Received: from gupta-dev2.jf.intel.com (HELO gupta-dev2.localdomain) ([10.54.74.119]) by orsmga006.jf.intel.com with ESMTP; 06 Sep 2021 22:36:46 -0700 Date: Mon, 6 Sep 2021 22:38:16 -0700 From: Pawan Gupta To: Hao Peng Cc: Xiaoyao Li , Borislav Petkov , tglx@linutronix.de, mingo@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/tsx: clear RTM and HLE when MSR_IA32_TSX_CTRL is not supported Message-ID: <20210907053816.qldtcxkxxv7hkzgv@gupta-dev2.localdomain> References: <77e8d483-4395-0017-300e-0886f75217bb@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07.09.2021 12:39, Hao Peng wrote: >On Tue, Sep 7, 2021 at 12:26 PM Xiaoyao Li wrote: >> >> On 9/7/2021 11:40 AM, Hao Peng wrote: >> > On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li wrote: >> >> >> >> On 9/7/2021 10:35 AM, Hao Peng wrote: >> >>> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li wrote: >> >>>> >> >>>> On 9/7/2021 9:47 AM, Hao Peng wrote: >> >>>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov wrote: >> >>>>>> >> >>>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote: >> >>>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports >> >>>>>>> RTM and HLE features, it will affect TAA mitigation. >> >>>>>>> >> >>>>>>> Signed-off-by: Peng Hao >> >>>>>>> --- >> >>>>>>> arch/x86/kernel/cpu/tsx.c | 7 +++++++ >> >>>>>>> 1 file changed, 7 insertions(+) >> >>>>>>> >> >>>>>>> diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c >> >>>>>>> index 9c7a5f049292..5e852c14fef2 100644 >> >>>>>>> --- a/arch/x86/kernel/cpu/tsx.c >> >>>>>>> +++ b/arch/x86/kernel/cpu/tsx.c >> >>>>>>> @@ -122,6 +122,13 @@ void __init tsx_init(void) >> >>>>>>> >> >>>>>>> if (!tsx_ctrl_is_supported()) { >> >>>>>>> tsx_ctrl_state = TSX_CTRL_NOT_SUPPORTED; >> >>>>>>> + >> >>>>>>> + /* If hypervisor does not support MSR_IA32_TSX_CTRL emulation, >> >>>>>>> + * but guest supports RTM and HLE features, it will affect TAA >> >>>>>>> + * (tsx_async_abort)mitigation. >> >>>>>>> + */ >> >>>>>>> + setup_clear_cpu_cap(X86_FEATURE_RTM); >> >>>>>>> + setup_clear_cpu_cap(X86_FEATURE_HLE); >> >>>> >> >>>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in >> >>>> taa_select_mitigation() >> >>>> >> >>>>>>> return; >> >>>>>>> } >> >>>>>> >> >>>>>> How does that even happen - the hypervisor does not support the MSR but >> >>>>>> "guest supports" TSX features?! >> >>>>>> >> >>>>>> I guess the guest is detecting it wrong. >> >>>>>> >> >>>>>> What hypervisor, what guest, how do I reproduce? >> >>>>>> >> >>>>> hypervisor is kvm, guest is linux too. >> >>>>>> Please give full details. >> >>>>>> >> >>>>> The host I used is kernel-5.4, and guest is kernel-5.13. >> >>>>> MSR_IA32_TSX_CTRL is exposed >> >>>>> to guest and guest to support RTM and HLE features, no direct >> >>>>> dependence. at the qemu I >> >>>>> started guest with -cpu host-model. >> >>>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not >> >>>>> exposed to guest. >> >>>> >> >>>> Does guest see TAA_NO bit? >> >>>> >> >>> Guest can't see taa_no, which requires updating qemu to solve. But I think >> >>> there is a compatibility process here. >> >> >> >> Anyway, there should be some existing code in kernel already to handle >> >> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't >> >> report MSR_TSX_CTRL nor TAA_NO. >> >> >> > Can you point out which patches ? At present, guest is kernel-5.13 >> > still has this problem. >> >> What's the output of 'cat >> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort' on your guest? >> >Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown. This suggests that the microcode is old. Can you please share the output of below cmds on host and guest: $ grep . /sys/devices/system/cpu/vulnerabilities/* $ lscpu $ grep microcode /proc/cpuinfo | uniq $ cat /proc/cmdline Thanks, Pawan