Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <cc344449-5f0b-51c7-bae8-6deb9be83702@intel.com>
Date:   Mon, 16 Jan 2023 13:15:29 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH v6 3/7] x86/cpu, kvm: Move the LFENCE_RDTSC / LFENCE
 always serializing feature
Content-Language: en-US
To:     Borislav Petkov <bp@alien8.de>,
        Kim Phillips <kim.phillips@amd.com>,
        Dave Hansen <dave.hansen@linux.intel.com>
Cc:     x86@kernel.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Joao Martins <joao.m.martins@oracle.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <seanjc@google.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Juergen Gross <jgross@suse.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Tony Luck <tony.luck@intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Alexey Kardashevskiy <aik@amd.com>, kvm@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230110224643.452273-1-kim.phillips@amd.com>
 <20230110224643.452273-5-kim.phillips@amd.com> <Y8WTnx/ukvdAEeoe@zn.tnic>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <Y8WTnx/ukvdAEeoe@zn.tnic>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 1/16/23 10:13, Borislav Petkov wrote:
>>  /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
>>  #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* "" AMD No Nested Data Breakpoints */
>> +#define X86_FEATURE_LFENCE_RDTSC	(20*32+ 2) /* "" LFENCE always serializing / synchronizes RDTSC */
> Hmm, a synthetic bit which gets replaced with a vendor one and then the other
> vendors set it too. I don't see why that cannot work but we probably should be
> careful here.
> 
> dhansen, am I missing an angle?

I don't think so.

I'd be surprised if we don't have a _few_ other cases like this around,
but nothing is coming to mind.  Either way, it doesn't seem problematic.