CSB Non-zero CC Reported Error Types

"Linuxppc-dev" <linuxppc-dev-bounces+hbab=
u=3Dus.ibm.com@lists.ozlabs.org>
wrote on 07/09/2020 04:22:10 AM:

> From: Michael Ellerman <mpe=
@ellerman.id.au>
>=
 To: Haren Myneni <haren@linux.ibm.com>
> Cc: tulioqm@br.ibm.com, abali@us.ibm.com,
linuxppc-
> dev@lists.ozlabs.org, rzinsly@linux.ibm.com
> Date: 07/09/2020 04:21 AM=

> Subject: [EXTERNAL] Re: [=
PATCH
1/2] powerpc/vas: Report proper error
> for address translation failu=
re
> Sent by: "L=
inuxppc-dev"
<linuxppc-dev-bounces
> +hbabu=3Dus.ibm.com@lists.ozlabs.org>
> 
> Haren Mynen=
i <haren@linux.ibm.com> writes:
> > DMA controller uses CC=
=3D5 internally for translation fault handling.
So
> > OS should be using CC=3D250 and should report this error to=
 the
user space
> > when NX encounters address translation failure on t=
he request
buffer.
> 
> That doesn't really explain *why* the OS must use =
CC=3D250.
> 
> Is it documented somewhere that 5 is for hardwar=
e use, and 250 is
for
> software?
Table 4-36. CSB Non-zero CC Reported Error Types<=
span style=3D" font-size:10pt">(P9 NX DD2 work book). Also footnote for CC=
=3D5 says I will add documentation
reference for CC=3D250 comment. 

> 
> > This patch defines CSB=5FCC=5FADDRESS=5FTRANSLAT=
ION(250) and updates
> > CSB.CC with this proper error code for us=
er space.
> 
> We still have:
> 
> #define CSB=5FCC=
=5FTRANSLATION   (5)
> 
> And it's very unclear where one =
or the other should be used.
> 
> Can one or the other get a na=
me that makes the distinction clear.

CSB=5FCC=5FTRANSLATION is added in 842
driver (nx-common-powernv.c) when NX is introduced (P7+). NX will not see
faults on kernel requests (cc=3D250) and even CC=3D5. 

<=
tt>Table 4-36: 
For CC=3D5: says Translation
CC=3D250:    says "Address
Translation Fault"
So I can say CRB=5FCC=5FADDRESS=5FTRANSLATION=5FFAULT
or CRN=5FCC=5FTRANSLATION=5FFAULT. This code path (also CRBs) should be gen=
eric,
so should not use like CRB=5FCC=5FNX=5FFAULT. 
Thanks
Haren

>=

> cheers
> 
> 
> > diff --git a/Documentation/=
powerpc/vas-api.rst b/Documentation/
> powerpc/vas-api.rst
> &g=
t; index 1217c2f..78627cc 100644
> > --- a/Documentation/powerpc/v=
as-api.rst
> > +++ b/Documentation/powerpc/vas-api.rst
> >=
; @@ -213,7 +213,7 @@ request buffers are not in memory. The 
> opera=
ting system handles the fault by
> >  updating CSB with the f=
ollowing data:
> >  
> >     csb.flags =3D=
 CSB=5FV;
> > -   csb.cc =3D CSB=5FCC=5FTRANSLATION;
> =
> +   csb.cc =3D CSB=5FCC=5FADDRESS=5FTRANSLATION;
> > &nb=
sp;   csb.ce =3D CSB=5FCE=5FTERMINATION;
> >     cs=
b.address =3D fault=5Faddress;
> >  
> > diff --git =
a/arch/powerpc/include/asm/icswx.h b/arch/powerpc/
> include/asm/icsw=
x.h
> > index 965b1f3..b1c9a57 100644
> > --- a/arch/powe=
rpc/include/asm/icswx.h
> > +++ b/arch/powerpc/include/asm/icswx.h=

> > @@ -77,6 +77,8 @@ struct coprocessor=5Fcompletion=5Fblock {> >  #define CSB=5FCC=5FCHAIN      (37)
>=
 >  #define CSB=5FCC=5FSEQUENCE      (38)
> &g=
t;  #define CSB=5FCC=5FHW      (39)
> > +/* Us=
er space address traslation failure */
> > +#define   CSB=5FC=
C=5FADDRESS=5FTRANSLATION   (250)
> >  
> > &nb=
sp;#define CSB=5FSIZE      (0x10)
> >  #define=
 CSB=5FALIGN      CSB=5FSIZE
> > diff --git a/arch/=
powerpc/platforms/powernv/vas-fault.c b/arch/
> powerpc/platforms/pow=
ernv/vas-fault.c
> > index 266a6ca..33e89d4 100644
> > --=
- a/arch/powerpc/platforms/powernv/vas-fault.c
> > +++ b/arch/powe=
rpc/platforms/powernv/vas-fault.c
> > @@ -79,7 +79,7 @@ static voi=
d update=5Fcsb(struct vas=5Fwindow *window,
> >     csb=
=5Faddr =3D (void =5F=5Fuser *)be64=5Fto=5Fcpu(crb->csb=5Faddr);
>=
 >  
> >     memset(&csb, 0, sizeof(csb));> > -   csb.cc =3D CSB=5FCC=5FTRANSLATION;
> > + &nbs=
p; csb.cc =3D CSB=5FCC=5FADDRESS=5FTRANSLATION;
> >     =
csb.ce =3D CSB=5FCE=5FTERMINATION;
> >     csb.cs =3D 0;=

> >     csb.count =3D 0;
> > -- 
> > =
1.8.3.1
> 