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: [PATCH] x86/fpu: Warn only when CPU-provided sizes less than
 struct declaration
To:     Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org,
        x86@kernel.org
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
        jon.grimm@amd.com,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Thomas Lendacky <Thomas.Lendacky@amd.com>
References: <1575363688-36727-1-git-send-email-suravee.suthikulpanit@amd.com>
 <b63e2111-b0c6-a716-3d99-88f91ad64e1d@intel.com>
 <68bdd6f0-a229-433a-9234-303a3b02b092@amd.com>
 <4b20cff5-6e16-3599-4fc1-4f51d7c18d1d@intel.com>
 <7a8fe748-2c57-295a-e6ed-8969c41462aa@amd.com>
 <d092bae0-69ea-0a57-4db5-6de074956564@intel.com>
From:   Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Message-ID: <bac4b1ee-de8c-5e50-dc11-ab432ca0f6af@amd.com>
Date:   Thu, 12 Dec 2019 13:52:44 +0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
In-Reply-To: <d092bae0-69ea-0a57-4db5-6de074956564@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
X-MS-Exchange-CrossTenant-Network-Message-Id: 819aa540-1d8e-43ef-249f-08d77ecfebd9
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2019 06:52:57.7960
 (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: I0fW2VWfaEW8ad3jJb0ruzOxp+Gax/JjldcEVSnQFZbbCDuHE+GZxwAe8KKmbBv4jd8I6d8kG9OkAptZ77rcVg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4141
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Dave,

On 12/11/2019 9:13 PM, Dave Hansen wrote:
> On 12/10/19 9:24 PM, Suravee Suthikulpanit wrote:
>> The value returned by ECX[1] indicates the alignment of state
>> component i when the compacted format of the extended region of an
>> XSAVE area is used (see Section 13.4.3). If ECX[1] returns 0, state
>> component i is located immediately following the preceding state
>> component; if ECX[1] returns 1, state component i is located on the
>> next 64-byte boundary following the preceding state component.
> 
> Essentially, if an implementation needs state alignment or (up to) 64
> bytes of padding, it could use this existing architecture for it.

Let me check with the HW folks and get back to you on this.

>> Please correct me if I am wrong, but I believe this is similar to the
>> case mentioned in the commit ef78f2a4bf84 ('x86/fpu: Check
>> CPU-provided sizes against struct declarations'), where it mentions
>> inconsistency b/w the MPX 'bndcsr' state and the C structures.
> 
> Yep, but I fixed that by padding the C structure, not silencing the
> warning.  Also *ALL* MPX implementations have had the same size for that
> state.

Ah I see. But that solution works because the MPX feature is only on Intel.
In case of PKRU, it seems that two hardware implementations have different
padding size for PKRU state. IIUC, Intel has padding of 4 bytes based on
the following struct.

/*
  * State component 9: 32-bit PKRU register.  The state is
  * 8 bytes long but only 4 bytes is used currently.
  */
struct pkru_state {
         u32                             pkru;
         u32                             pad;
} __packed;

Therefore, I agree with you that we might need to use the ECX[1].
Let me confirm this and get back to you.

Thanks,
Suravee