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;
Date:   Fri, 23 Dec 2022 11:34:05 -0800
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     Peter Zijlstra <peterz@infradead.org>,
        "Li, Xin3" <xin3.li@intel.com>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
        "Christopherson,, Sean" <seanjc@google.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>
Subject: Re: [RFC PATCH 14/32] x86/fred: header file with FRED definitions
User-Agent: K-9 Mail for Android
In-Reply-To: <Y6RVvRg20Xc6IR4k@hirez.programming.kicks-ass.net>
References: <20221220063658.19271-1-xin3.li@intel.com> <20221220063658.19271-15-xin3.li@intel.com> <Y6F4s0K2b2G8aMve@hirez.programming.kicks-ass.net> <BN6PR1101MB21615569318BD964A2855F44A8EB9@BN6PR1101MB2161.namprd11.prod.outlook.com> <Y6RVvRg20Xc6IR4k@hirez.programming.kicks-ass.net>
Message-ID: <BBD4EA67-C076-4718-93C6-EB25A59C342B@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On December 22, 2022 5:03:57 AM PST, Peter Zijlstra <peterz@infradead=2Eorg=
> wrote:
>On Wed, Dec 21, 2022 at 02:58:06AM +0000, Li, Xin3 wrote:
>
>> > > +/* Flags above the CS selector (regs->csl) */
>> > > +#define FRED_CSL_ENABLE_NMI		_BITUL(28)
>> > > +#define FRED_CSL_ALLOW_SINGLE_STEP	_BITUL(25)
>> > > +#define FRED_CSL_INTERRUPT_SHADOW	_BITUL(24)
>> >=20
>> > What's the state of IBT WAIT-FOR-ENDBR vs this? That really should al=
so get a
>> > high CS bit=2E
>>=20
>> FRED does provide more possibilities :)
>
>That's not an answer=2E IBT has a clear defect and FRED *should* fix it=
=2E

You are not wrong, of course=2E That being said, we have not wanted to hit=
ch too many things to the FRED baseline, lest it ends up delayed for implem=
entation/validation reasons=2E The important thing is that FRED *does* prov=
ide the mechanism for addressing that even if it does not make the first im=
plementation=2E