Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE1E1C05027 for ; Fri, 17 Feb 2023 22:01:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229714AbjBQWBp (ORCPT ); Fri, 17 Feb 2023 17:01:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229555AbjBQWBn (ORCPT ); Fri, 17 Feb 2023 17:01:43 -0500 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0342D59726 for ; Fri, 17 Feb 2023 14:01:41 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id a12so2451855wro.7 for ; Fri, 17 Feb 2023 14:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=S+RWIU7oYjEmeKhN1BRM+dPgJ9kaVMQBvH0lTKx4gCo=; b=P7KlUd8vpj+WjFNp4aWlFlmB/DX+kLVPD3QP7QX7aLNUWsHdPIdNFpbudIqZ+cvY3W HE0ybe5TzouaO117yLXbatR1gY8rf1h/o+Bbbu3X5MDM0ZuWico3g9t9+bxjoOmydgzx /ZSgmlxE3ZAvzI1Fz/TVDDEHgO5h2G13bQcwPcyDdQd9nb86jlNZWruMtK/sN29vC8EN qKYcgdkk5hp4jtKsLRINg8vRhzyDDSkhTbmlmWZWtBZVzH3kKZEN3c8jPfDaXOCTZ1+/ m7EmHx5R0xdNkHUBsI3nYaZWB6exavhe51sDW3KSusJYEPjUMh4WO7GAZe3VRKgtC57A DXXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=S+RWIU7oYjEmeKhN1BRM+dPgJ9kaVMQBvH0lTKx4gCo=; b=i9fj0qLAs9cFgnls7UrbXkyPcDmwzUWGiQVJn1mfwPN567nX7u6TQYESA7mUSuL+db FY+wF+pi7fmIL1L7d6loslskTYdE7lp2Un+yqlU6ITnIbWMoxwTMh57ppvt1aVTm4a2Z 5roGvhLV3qSBUqCWB8KBqUMUSjdcQtK9oXNX3FeJy61PBcJqPY3HNJCCU/g/zRuV2B1/ bdDAlHNLrqfDTz1ht/omWXhu1Tu8ruMfe/CAykso5kpZ/A0UfNj4MZOFKhdkAJ+8rH3t MMOOuIK8/Al7aBvoudyqUPYMHGyyJJopI7lLvzMD2lrjeZFbTGDSk6SwO8qi9wXu5GUK xG5w== X-Gm-Message-State: AO0yUKVVNS+PLQFcqZQOyWt//X9K7FEJ4MZ/YdKx5xatKWIwhu0PnU0+ LoYrfaBTlXLy4XA04gXanaXEcBwaWaaJIRThIWPtEA== X-Google-Smtp-Source: AK7set8Y5jxAp9swg/itPrwFcKyXyojx4iwM90gLmILXSZ0Xoyfrwexebu9w/TfSPp/vznOWaghs7HSgvJ2FQTvEhzU= X-Received: by 2002:a5d:640e:0:b0:2c4:dbc:8e34 with SMTP id z14-20020a5d640e000000b002c40dbc8e34mr229772wru.123.1676671299303; Fri, 17 Feb 2023 14:01:39 -0800 (PST) MIME-Version: 1.0 References: <20230214184606.510551-1-mizhang@google.com> <20230214184606.510551-4-mizhang@google.com> In-Reply-To: <20230214184606.510551-4-mizhang@google.com> From: Aaron Lewis Date: Fri, 17 Feb 2023 22:01:27 +0000 Message-ID: Subject: Re: [PATCH v2 3/7] KVM: selftests: x86: Add check of CR0.TS in the #NM handler in amx_test To: Mingwei Zhang Cc: Sean Christopherson , Paolo Bonzini , kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , Venkatesh Srinivas , "Chang S. Bae" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 14, 2023 at 6:46 PM Mingwei Zhang wrote: > > Add check of CR0.TS[bit 3] before the check of IA32_XFD_ERR in the #NM > handler in amx_test. This is because XFD may not be the only reason of > the IA32_XFD MSR and the bitmap corresponding to the state components > required by the faulting instruction." (Intel SDM vol 1. Section 13.14) > > Add the missing check of CR0.TS. > > Signed-off-by: Mingwei Zhang > --- > tools/testing/selftests/kvm/x86_64/amx_test.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/testing/selftests/kvm/x86_64/amx_test.c b/tools/testing/selftests/kvm/x86_64/amx_test.c > index aac727ff7cf8..847752998660 100644 > --- a/tools/testing/selftests/kvm/x86_64/amx_test.c > +++ b/tools/testing/selftests/kvm/x86_64/amx_test.c > @@ -215,6 +215,7 @@ void guest_nm_handler(struct ex_regs *regs) > { > /* Check if #NM is triggered by XFEATURE_MASK_XTILEDATA */ > GUEST_SYNC(7); > + GUEST_ASSERT((get_cr0() & X86_CR0_TS) == 0); Can't we infer that the #NM is the result of an XFD error due to the fact that IA32_XFD_ERR is set? Is this check needed? SDM vol 1, 13.14, EXTENDED FEATURE DISABLE (XFD) - Device-not-available exceptions that are not due to XFD - those resulting from setting CR0.TS to 1 - do not modify the IA32_XFD_ERR MSR. > GUEST_ASSERT(rdmsr(MSR_IA32_XFD_ERR) == XFEATURE_MASK_XTILEDATA); > GUEST_SYNC(8); > GUEST_ASSERT(rdmsr(MSR_IA32_XFD_ERR) == XFEATURE_MASK_XTILEDATA); > -- > 2.39.1.581.gbfd45094c4-goog >