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;
Subject: Re: AMD DC graphics display code enables -mhard-float, -msse, -msse2
 without any visible FPU state protection
To:     Jann Horn <jannh@google.com>,
        Harry Wentland <harry.wentland@amd.com>,
        Leo Li <sunpeng.li@amd.com>, amd-gfx@lists.freedesktop.org,
        Alex Deucher <alexander.deucher@amd.com>,
        "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        the arch/x86 maintainers <x86@kernel.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Andy Lutomirski <luto@kernel.org>
References: <CAG48ez2Sx4ELkM94aD_h_J7K7KBOeuGmvZLKRkg3n_f2WoZ_cg@mail.gmail.com>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
Message-ID: <4c5fe55d-9db9-2f61-59b2-1fb2e1b45ed0@amd.com>
Date:   Thu, 2 Apr 2020 09:33:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
In-Reply-To: <CAG48ez2Sx4ELkM94aD_h_J7K7KBOeuGmvZLKRkg3n_f2WoZ_cg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2a02:908:1252:fb60:be8a:bd56:1f94:86e7] (2a02:908:1252:fb60:be8a:bd56:1f94:86e7) by AM0PR01CA0099.eurprd01.prod.exchangelabs.com (2603:10a6:208:10e::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Thu, 2 Apr 2020 07:33:58 +0000
X-Originating-IP: [2a02:908:1252:fb60:be8a:bd56:1f94:86e7]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: d5416cc3-da8f-47b6-e246-08d7d6d837a4
X-MS-TrafficTypeDiagnostic: DM6PR12MB3913:|DM6PR12MB3913:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <DM6PR12MB39136CF72994DCDEAC4BA6EF83C60@DM6PR12MB3913.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0361212EA8
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR12MB4401.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(2616005)(52116002)(31696002)(186003)(4326008)(110136005)(7416002)(16526019)(54906003)(478600001)(8676002)(6666004)(36756003)(6636002)(66476007)(81166006)(66946007)(66556008)(81156014)(316002)(8936002)(86362001)(2906002)(31686004)(5660300002)(6486002);DIR:OUT;SFP:1101;
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: hOMmNFLzX9IgZhSD29Bs9/bUaNVQrCWKAtMg5R+vzlgGn59E4Ujd0UfzdEM1TX/mfkZjJj/SRV3ppjkoZiVB+BISeb2Fq9+ReNxOR8TzcfzabUrTsY52Guppo9ctDLVwMaQ/xuOeO2SQtKokEaf2m3pjRNNrepHaLtuxw0g9CEqrZz86aghNv2KKN7GDZy0IK65kSAGTV3zcGlgHXhv49PXaKop+EldeCNWIrpmYrM/VVHWz8sgcUMKZs1He/tMbMcDyZJtufnu6+xyX9p//Q8MycfICCzkZI+QIKUCVu1GrOnldNgYimbWtDTMy8wajJ7GRn0oC4QyvrZaHLoVkYCDEBYMP20nEXj+5YFvV6eI/Ci1CSXsqbMtlDKsVy1+p4v7KfiPdxv57Gfl4ByxDe8AYPoLdjBW4ByEA5w9xmWgYeoUl1+tQd4wKB1jCjGaP
X-MS-Exchange-AntiSpam-MessageData: 6/BzDC+dmV3F/VSZE936k0LsPFi/EB8W8AHyHle4oTh34UDpSe482Em/qTb1rM2rkIv5EOxOhmNrZomXsL28KMjrXNXGZW6fgkXfxe8kxYoYUiRR7d+VYPyvM8he210Hwj6MeE/vEQD42bDkTUtzp+FZvTYQod+NyWEfd4sAAOBIBupNzf7muf/N58j+j+Ae+mgDnhsvDGisP34V+PnaBQ==
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d5416cc3-da8f-47b6-e246-08d7d6d837a4
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 07:34:03.4870
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: LoJAvslZ1LA2L5uhpz8Z4FdAb4u6T5Azv+bk8dw+8EvHUb54qUMotoyU/UAY+So7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3913
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Jann,

Am 02.04.20 um 04:34 schrieb Jann Horn:
> [x86 folks in CC so that they can chime in on the precise rules for this stuff]
>
> Hi!
>
> I noticed that several makefiles under drivers/gpu/drm/amd/display/dc/
> turn on floating-point instructions in the compiler flags
> (-mhard-float, -msse and -msse2) in order to make the "float" and
> "double" types usable from C code without requiring helper functions.
>
> However, as far as I know, code running in normal kernel context isn't
> allowed to use floating-point registers without special protection
> using helpers like kernel_fpu_begin() and kernel_fpu_end() (which also
> require that the protected code never blocks). If you violate that
> rule, that can lead to various issues - among other things, I think
> the kernel will clobber userspace FPU register state, and I think the
> kernel code can blow up if a context switch happens at the wrong time,
> since in-kernel task switches don't preserve FPU state.
>
> Is there some hidden trick I'm missing that makes it okay to use FPU
> registers here?
>
> I would try testing this, but unfortunately none of the AMD devices I
> have here have the appropriate graphics hardware...

yes, using the floating point calculations in the display code has been 
a source of numerous problems and confusion in the past.

The calls to kernel_fpu_begin() and kernel_fpu_end() are hidden behind 
the DC_FP_START() and DC_FP_END() macros which are supposed to hide the 
architecture depend handling for x86 and PPC64.

This originated from the graphics block integrated into AMD CPU (where 
we knew which fp unit we had), but as far as I know is now also used for 
dedicated AMD GPUs as well.

I'm not really a fan of this either, but so far we weren't able to 
convince the hardware engineers to not use floating point calculations 
for the display stuff.

Regards,
Christian.