Messages in this thread | | | Date | Mon, 27 Apr 2020 18:08:08 -0700 | From | "Raj, Ashok" <> | Subject | Re: [PATCH 6/7] x86/traps: Fix up invalid PASID |
| |
Hi Thomas,
On Tue, Apr 28, 2020 at 02:54:59AM +0200, Thomas Gleixner wrote: > Ashok, > > "Raj, Ashok" <ashok.raj@intel.com> writes: > > On Sun, Apr 26, 2020 at 05:25:06PM +0200, Thomas Gleixner wrote: > >> 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 :-) > > Sigh. > > > 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. > > I know that the HW people's mantra is that everything can be fixed in > software and therefore slapping new features into the CPUs can be done > without thinking about the consequeses. > > But we all know from painful experience that this is fundamentally wrong > unless there is a really compelling reason.
:-)... I'm still looking for the quote from Linus about RAS before he went to behavior school.
> > For new features there is absolutely no reason at all. > > Can HW people pretty please understand that hardware and software have > to be co-designed and not dictated by 'some uarch reasons'. This is > nothing fundamentally new. This problem existed 30+ years ago, is well > documented and has been ignored forever. I'm tired of that, really. > > But as this seems to be unsolvable for the problem at hand can you > please document the inability, unwillingness or whatever in the > changelog?
Most certainly!
> > The question why this brand new_ ENQCMD + invalid PASID induced #GP does > not generate an useful error code and needs heuristics to be dealt with > is pretty obvious. >
Cheers, Ashok
| |