[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUuh1habqkhk8y4B@otcwcpicx3.sc.intel.com>
Date: Wed, 22 Sep 2021 21:36:22 +0000
From: Fenghua Yu <fenghua.yu@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...el.com>,
Tony Luck <tony.luck@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Joerg Roedel <joro@...tes.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Dave Jiang <dave.jiang@...el.com>,
Jacob Jun Pan <jacob.jun.pan@...el.com>,
Ashok Raj <ashok.raj@...el.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
iommu@...ts.linux-foundation.org, x86 <x86@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP
Hi, Peter,
On Wed, Sep 22, 2021 at 11:11:45PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 22, 2021 at 11:07:22PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 20, 2021 at 07:23:45PM +0000, Fenghua Yu wrote:
> > > +static bool fixup_pasid_exception(void)
> > > +{
> > > + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
> > > + return false;
> > > +
> > > + return __fixup_pasid_exception();
> > > +}
>
> That is, shouldn't the above at the very least decode the instruction
> causing the #GP and check it's this ENQCMD thing?
There were comments on a previous version when we used #GP fixup method:
https://lore.kernel.org/linux-iommu/f6d34d59-e6eb-ee9f-d247-8fb2f0e37549@intel.com/
There are three reasons for not decoding the instruction:
1. Parsing the instruction sets bad architectural precedent and is ugly.
2. The instruction could be modified (e.g. JVM) while decoding the
instruction. It's.
3. Decoding is more complex than this patch and doesn't worth it.
Thanks.
-Fenghua
Powered by blists - more mailing lists