Messages in this thread | | | Date | Mon, 27 Apr 2020 15:46:46 -0700 | From | "Raj, Ashok" <> | Subject | Re: [PATCH 6/7] x86/traps: Fix up invalid PASID |
| |
Hi Thomas
On Sun, Apr 26, 2020 at 05:25:06PM +0200, Thomas Gleixner wrote: > Fenghua Yu <fenghua.yu@intel.com> writes: > > A #GP fault is generated when ENQCMD instruction is executed without > > a valid PASID value programmed in. > > Programmed in what? > > > The #GP fault handler will initialize the current thread's PASID MSR. > > > > The following heuristic is used to avoid decoding the user instructions > > to determine the precise reason for the #GP fault: > > 1) If the mm for the process has not been allocated a PASID, this #GP > > cannot be fixed. > > 2) If the PASID MSR is already initialized, then the #GP was for some > > other reason > > 3) Try initializing the PASID MSR and returning. If the #GP was from > > an ENQCMD this will fix it. If not, the #GP fault will be repeated > > and we will hit case "2". > > > > Suggested-by: Thomas Gleixner <tglx@linutronix.de> > > Just for the record I also suggested to have a proper errorcode in the > #GP for ENQCMD and I surely did not suggest to avoid decoding the user > instructions.
We certainly discussed the possiblity of adding an error code to identiy #GP due to ENQCMD with our HW architects.
There are only a few cases that have an error code, like move to segment with an invalid value for instance. There were a few but i don't recall that entire list.
Since the error code is 0 in most places, there isn't plumbing in hw to return this value in all cases. It appeared that due to some uarch reasons it wasn't as simple as it appears to /me sw kinds :-)
So after some internal discussion we decided to take the current approach. Its possible that if the #GP was due to some other reason we might #GP another time. Since this wasn't perf or speed path we took this lazy approach.
We will keep tabs with HW folks for future consideration.
| |