Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753403AbdIFDpj (ORCPT ); Tue, 5 Sep 2017 23:45:39 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:37629 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752226AbdIFDpi (ORCPT ); Tue, 5 Sep 2017 23:45:38 -0400 From: Boris Ostrovsky To: thomas.lendacky@amd.com Cc: X86 ML , "linux-kernel@vger.kernel.org" , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner Subject: SME/32-bit regression Message-ID: <4c07148a-5d97-0fc2-aa9b-1db31429736d@oracle.com> Date: Tue, 5 Sep 2017 23:45:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 545 Lines: 12 It appears there is a regression for 32-bit kernels due to SME changes. I bisected my particular problem (Xen PV guest) to 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() errors on baremetal. This seems to be caused by sme_me_mask being an unsigned long as opposed to phys_addr_t (the actual problem is that __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably won't work for non-PAE which I haven't tried). -boris