Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
To:     Vineet Gupta <Vineet.Gupta1@synopsys.com>,
        "linux-snps-arc@lists.infradead.org" 
        <linux-snps-arc@lists.infradead.org>
CC:     Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] ARC: handle DSP presence in HW
Thread-Topic: [PATCH v2 2/4] ARC: handle DSP presence in HW
Thread-Index: AQHV8ykv/JMPPGHpokOBrJCtc4/bvKg8Q+KAgAV+8B0=
Date:   Tue, 10 Mar 2020 12:18:15 +0000
Message-ID: <BY5PR12MB40344989C3CB5881729F660CDEFF0@BY5PR12MB4034.namprd12.prod.outlook.com>
References: <20200305200252.14278-1-Eugeniy.Paltsev@synopsys.com>
 <20200305200252.14278-3-Eugeniy.Paltsev@synopsys.com>,<2d11b6d9-a37a-8cc3-1feb-a9dbc345de12@synopsys.com>
In-Reply-To: <2d11b6d9-a37a-8cc3-1feb-a9dbc345de12@synopsys.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: synopsys.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dda1ec26-6ecc-46fa-98f1-08d7c4ed1c6c
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 12:18:15.8261
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c33c9f88-1eb7-4099-9700-16013fd9e8aa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3WsxxZe6+WncowQJ7yNEW5Z/0oyw3pYIoOwRHX3CUTxnGNgboGmCNw9cVE1qK7g9V7IQYQTsNLZND+ir9WoswQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4035
X-OriginatorOrg: synopsys.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>From: Vineet Gupta <vgupta@synopsys.com>=0A=
>Sent: Saturday, March 7, 2020 03:12=0A=
>To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org=0A=
>Cc: Alexey Brodkin; linux-kernel@vger.kernel.org=0A=
>Subject: Re: [PATCH v2 2/4] ARC: handle DSP presence in HW=0A=
>=0A=
>On 3/5/20 12:02 PM, Eugeniy Paltsev wrote:=0A=
>> In case of DSP extension presence in HW some instructions=0A=
>> (related to integer multiply, multiply-accumulate, and divide=0A=
>> operation) executes on this DSP execution unit. So their=0A=
>> execution will depend on dsp configuration register (DSP_CTRL)=0A=
>>=0A=
>> As we want these instructions to execute the same way regardless=0A=
>> of DSP presence we need to set DSP_CTRL properly. However this=0A=
>> register can be modified bu any usersace app therefore any=0A=
>> usersace may break kernel execution.=0A=
>>=0A=
>> Fix that by configure DSP_CTRL in CPU early code and in IRQs=0A=
>> entries.=0A=
>=0A=
> How about below ....=0A=
> =0A=
> "When DSP extensions are present, some of the regular integer instruction=
s such as=0A=
> DIV, MACD etc are executed in the DSP unit with semantics alterable by fl=
ags in=0A=
> DSP_CTRL aux register. This register is writable by userspace and thus ca=
n=0A=
> potentially affect corresponding instructions in kernel code, intentional=
ly or=0A=
> otherwise. So safegaurd kernel by effectively disabling DSP_CTRL upon boo=
tup and=0A=
> every entry to kernel.=0A=
> =0A=
> Do note that for this config we simply zero out the DSP_CTRL reg assuming=
=0A=
> userspace doesn't really care about DSP. The next patch caters to the DSP=
 aware=0A=
> userspace which this actually saved/restored upon kernel entry."=0A=
>From: Vineet Gupta <vgupta@synopsys.com>=0A=
>Sent: Saturday, March 7, 2020 03:12=0A=
>To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org=0A=
>Cc: Alexey Brodkin; linux-kernel@vger.kernel.org=0A=
>Subject: Re: [PATCH v2 2/4] ARC: handle DSP presence in HW=0A=
>=0A=
>On 3/5/20 12:02 PM, Eugeniy Paltsev wrote:=0A=
>> In case of DSP extension presence in HW some instructions=0A=
>> (related to integer multiply, multiply-accumulate, and divide=0A=
>> operation) executes on this DSP execution unit. So their=0A=
>> execution will depend on dsp configuration register (DSP_CTRL)=0A=
>>=0A=
>> As we want these instructions to execute the same way regardless=0A=
>> of DSP presence we need to set DSP_CTRL properly. However this=0A=
>> register can be modified bu any usersace app therefore any=0A=
>> usersace may break kernel execution.=0A=
>>=0A=
>> Fix that by configure DSP_CTRL in CPU early code and in IRQs=0A=
>> entries.=0A=
>=0A=
> How about below ....=0A=
=0A=
> =0A=
> "When DSP extensions are present, some of the regular integer instruction=
s such as=0A=
> DIV, MACD etc are executed in the DSP unit with semantics alterable by fl=
ags in=0A=
> DSP_CTRL aux register. This register is writable by userspace and thus ca=
n=0A=
> potentially affect corresponding instructions in kernel code, intentional=
ly or=0A=
> otherwise. So safegaurd kernel by effectively disabling DSP_CTRL upon boo=
tup and=0A=
> every entry to kernel.=0A=
> =0A=
> Do note that for this config we simply zero out the DSP_CTRL reg assuming=
=0A=
> userspace doesn't really care about DSP. The next patch caters to the DSP=
 aware=0A=
> userspace which this actually saved/restored upon kernel entry."=