Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3854875pxj; Mon, 24 May 2021 16:59:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzf3rdizrkwEMUVkbtwIB5/7YE1Ck97gUbfXw9rbjrZKt/sIMipfK9UFbcNojClZM0xbFqI X-Received: by 2002:a92:7c02:: with SMTP id x2mr18652524ilc.8.1621900756631; Mon, 24 May 2021 16:59:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621900756; cv=none; d=google.com; s=arc-20160816; b=uxeRyZnxGFiGOJYA2wfknyfGqQgQ5PsjStNicdzJXRoMemGV45cujKWMcSCk8ecbvm hBh33q6G1B+gq2zDxIdWj7Dgf+l3Skz0uVR7rjfHqOZ9m3i3pq+SFYPfRXRug4aaxq1p 6Upv3gPnCJeEUC96cQux4G2yu56EiSyOpnoOMW2pBI/feCeKHOshtyKVIwM8cOFZzYAl IqqYfMilEaTCL+lgSSZx49XmS9uaa8Q4w9eOS9+/vzbIIh80vBcU2DouTTXwUfQLdnC8 PRBflq8TY74v7gmxkyHRBh4UD8YrA4no5ekvCSFQhH2gqHLqq5Yie12OO4TLnOth++Jy BIaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=VXDvybtYbaA/WSLW3M8pJycbeN9ie3uJZCSoeU17yO4=; b=rfVm9yb26Gh96er84nrD2HPf+21g5VUD0/hr2S5GNFmibZVPNhOlOkTev692jUshez fhvWUsVTHT6Os+YDMEibdzKTGkGA8VDeT2Q9EMuqI4Y6XnaFQ6GubyIDjXy/EhnHSy6v T+y2TtH+TXz8wAvcVd57HTCv6Tc9tmOJI5r1xAKGDEOuvgFH8OrAjhQ+DgK9EF/fRATX YTiuEQRhtlx+oad/WktH+jg3KU2Va3R9Dr2PIiQ+Kn9rilIrkax5JFr1/VL7+clvaL7z Mzp8r6z6nOZ5X6UrI01s7Bc8WTjkPL2H5BGGj3r8bi0WSXwun4IDCXktFtQsKaOTkdKL okfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Hx86I9k1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j22si8158628jat.22.2021.05.24.16.59.03; Mon, 24 May 2021 16:59:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Hx86I9k1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233872AbhEXVaG (ORCPT + 99 others); Mon, 24 May 2021 17:30:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbhEXVaF (ORCPT ); Mon, 24 May 2021 17:30:05 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2256FC061574 for ; Mon, 24 May 2021 14:28:37 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id lx17-20020a17090b4b11b029015f3b32b8dbso10238549pjb.0 for ; Mon, 24 May 2021 14:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VXDvybtYbaA/WSLW3M8pJycbeN9ie3uJZCSoeU17yO4=; b=Hx86I9k1r8WTQK+7RJJk0K+XsWt7hzlR5DPrVnvIKljyxdcdE5s7KywgdkPD2TjNHP NsaIsTjhihIqOZzfzNWFCGN+ObVkGd+YFp+EmTYyeZdyg8f/bBCFXVJeFex2AI+1nAUB G6+jBqV7W559zXsGtv6drRKhO0Z4slsOVR269zhhiD/db3lNXcvNTwrYsRIs6CjwwGG+ ZsJlkWnQwhSc5NthytXMjqeFSJC+eequ0ymGUt/5uvLExHHY500YBhMLSN23izR8XfT2 NqenXszlsX+IqCB7dXPFZYO2Gdc6lQgbfsNCOTmfxizw2pVBuEOlLWgA+U4OJhNO5s8w /9NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VXDvybtYbaA/WSLW3M8pJycbeN9ie3uJZCSoeU17yO4=; b=FAL2vwhxBpNGbPmZElAR+77dYGQfn0r5FcvQx0yQIIyMu8PIszEYlz33SN7ycc/8pf HsZ4LGd9bGBNar8FZIrAJVByJOVtw3LTapa5l/kEcczAALBBCdi87tDYgIWl8yd/dXDQ JkLA71VAvSJXucP2NSuaj7vbdawWm4YFAK8Tnign5qVyvMqB3eAKvYsiXzIpnqOLX/TK uDS95MxCV9/9fCjQxWmnL227WtbnneWZD0CTWxhAk4TUGiaFz1NAzQNZcWF1k2wh646T nwSTiDvKk5+FIIB0r4UxHRF5P817V1Ym0By7dEEIJkEbWIUcC+lpIPCmohPodr9IXAoA uA1Q== X-Gm-Message-State: AOAM532Y9EAD90hsPQNAyX7bLreBT3oYMgijJQkEylRMoCFK4q+l14iK FeXB+bu2ES78L2GtoEvGN40nzODkYrV/8w== X-Received: by 2002:a17:902:b585:b029:f6:5cd5:f128 with SMTP id a5-20020a170902b585b02900f65cd5f128mr22731955pls.43.1621891716493; Mon, 24 May 2021 14:28:36 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id y1sm12007937pfn.13.2021.05.24.14.28.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 14:28:35 -0700 (PDT) Date: Mon, 24 May 2021 21:28:32 +0000 From: Sean Christopherson To: Jing Liu Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, jing2.liu@intel.com Subject: Re: [PATCH RFC 5/7] kvm: x86: Revise CPUID.D.1.EBX for alignment rule Message-ID: References: <20210207154256.52850-1-jing2.liu@linux.intel.com> <20210207154256.52850-6-jing2.liu@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210207154256.52850-6-jing2.liu@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 07, 2021, Jing Liu wrote: > CPUID.0xD.1.EBX[1] is set if, when the compacted format of an XSAVE > area is used, this extended state component located on the next > 64-byte boundary following the preceding state component (otherwise, > it is located immediately following the preceding state component). > > AMX tileconfig and tiledata are the first to use 64B alignment. > Revise the runtime cpuid modification for this rule. > > Signed-off-by: Jing Liu > --- > arch/x86/kvm/cpuid.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 04a73c395c71..ee1fac0a865e 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -35,12 +35,17 @@ static u32 xstate_required_size(u64 xstate_bv, bool compacted) > { > int feature_bit = 0; > u32 ret = XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET; > + bool is_aligned = false; > > xstate_bv &= XFEATURE_MASK_EXTEND; > while (xstate_bv) { > if (xstate_bv & 0x1) { > u32 eax, ebx, ecx, edx, offset; > cpuid_count(0xD, feature_bit, &eax, &ebx, &ecx, &edx); > + /* ECX[2]: 64B alignment in compacted form */ > + is_aligned = !!(ecx & 2); > + if (is_aligned && compacted) I'd forego the local is_aligned, and also check "compacted" first so that the uncompacted variant isn't required to evaluated ecx. And the real reason I am responding... can you post this as a standalone patch? I stumbled across the "aligned" flag when reading through the SDM for a completely unrelated reason, and also discovered that the flag has been documented since 2016. While AMX may be the first to "officially" utilize the alignment flag, the flag itself is architectural and not strictly limited to AMX. > + ret = ALIGN(ret, 64); > offset = compacted ? ret : ebx; > ret = max(ret, offset + eax); > } > -- > 2.18.4 >