From mboxrd@z Thu Jan 1 00:00:00 1970 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 1D808C6FD1D for ; Thu, 30 Mar 2023 19:37:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232262AbjC3Tht (ORCPT ); Thu, 30 Mar 2023 15:37:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232217AbjC3Thr (ORCPT ); Thu, 30 Mar 2023 15:37:47 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85A326195 for ; Thu, 30 Mar 2023 12:37:46 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id w14-20020a170902e88e00b001a238a5946cso9167220plg.11 for ; Thu, 30 Mar 2023 12:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680205066; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=NkWLHZW0sQsmSN+6OnRpZy+vDJdcHjDc+c5diHQwuNM=; b=lg7Mqv7PwZJpz9bkaWubUTBK7nwFxEOmGodCBS0Zeqt/RCcb5TIrDGbOmw6HCP28/6 Nh71oVjqUHYfAsK4hhOv7c67UOOUlUeyKXsm07+Fy8v9i+57dhO0aRdonrNnXUvirFVT mBVv7W+MBb3xW5no5hus0WEihXvkKlSiAgxS6RcGPk5LHBZwMV7zZAE3Cd+iQR82X9iw 9KlwRZJhNwKASj1oeEbaWec1dudvFaYiMuaTyk4aeFv7J1k8LreuYMBzRBWXbphEM9LG 5SvjeI2pi7qu+BdtKcdLk61mZJXWq6PuPZ/2tw6dupcbnLAtF5rmBCHzgzrdEj6guyIL 9ahQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680205066; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NkWLHZW0sQsmSN+6OnRpZy+vDJdcHjDc+c5diHQwuNM=; b=pKZw1aCgyHD4Y7+SuoydPvvhrp77XLdtuFMSUWVP26ZKaOY1Rk6GQfBTjIMQ0sbAiW XT0cdLqI/bA8PKYwrXamiNEcr8E0DAnquPj/7cjxeNW+JS8NSknQZzdonfEU8kCrtrZE UE6nfvFIspUJSr61zOOYUaWtIpvK4uH27f/FJz+61cIu4sj/eStDlzV/ur6A7jKv7JdU wGjvTz6ncadVPZYx7zB20sepVN3KEMZzIAQeWPvZxje9M0UB8ncxBDmTXKCjhBoYoW99 X7X1E4p8u2xGIvPN8erNMuZ2rO4YWz4zhw+cQgzBqnAK5SFHcSQIFM7ah7T90fO0CvBg qorA== X-Gm-Message-State: AAQBX9eOXu7Rg4HAimZNXkHTrByFxcokAFiFmPwlAKT8jmQkdH+kPFEw 5qeTDgkLete2gZ/43c7U75s6u4hLQcs= X-Google-Smtp-Source: AKy350ZhugBdBge6dVmLkF2+aGDettukZd1/SI5qNwtiDRyudPkp0xTio5VDPHnFN9mdpYJhiTfW8ocRaZI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:e104:0:b0:507:3e33:4390 with SMTP id z4-20020a63e104000000b005073e334390mr2160704pgh.6.1680205066070; Thu, 30 Mar 2023 12:37:46 -0700 (PDT) Date: Thu, 30 Mar 2023 12:37:44 -0700 In-Reply-To: <754c052c-b575-4abc-605a-fff7d09c4a65@redhat.com> Mime-Version: 1.0 References: <0dcae003-d784-d4e6-93a2-d8cc9a1e3bc1@redhat.com> <754c052c-b575-4abc-605a-fff7d09c4a65@redhat.com> Message-ID: Subject: Re: The "memory" test is failing in the kvm-unit-tests CI From: Sean Christopherson To: Thomas Huth Cc: Paolo Bonzini , KVM , Cole Robinson Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Mar 30, 2023, Thomas Huth wrote: > On 29/03/2023 21.11, Sean Christopherson wrote: > > On Wed, Mar 29, 2023, Thomas Huth wrote: > > > > > > Hi, > > > > > > I noticed that in recent builds, the "memory" test started failing in the > > > kvm-unit-test CI. After doing some experiments, I think it might rather be > > > related to the environment than to a recent change in the k-u-t sources. > > > > > > It used to work fine with commit 2480430a here in January: > > > > > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/3613156199#L2873 > > > > > > Now I've re-run the CI with the same commit 2480430a here and it is failing now: > > > > > > https://gitlab.com/thuth/kvm-unit-tests/-/jobs/4022074711#L2733 > > > > Can you provide the logs from the failing test, and/or the build artifacts? I > > tried, and failed, to find them on Gitlab. > > Yes, that's still missing in the CI scripts ... I'll try to come up with a > patch that provides the logs as artifacts. > > Meanwhile, here's a run with a manual "cat logs/memory.log": > > https://gitlab.com/thuth/kvm-unit-tests/-/jobs/4029213352#L2726 > > Seems like these are the failing memory tests: > > FAIL: clflushopt (ABSENT) > FAIL: clwb (ABSENT) More than likely what is happening is that the platform supports CLFLUSHOPT and CLWB (possibly even via a ucode patch update), but the CPUID bits are not being enumerated to the guest. Neither VMX nor SVM has intercept controls for the instructions, so KVM has no way to enforce the the guest's CPUID model. E.g. the failures can be reproduce by manually hiding the features: rkt ./x86/run x86/memory.flat -smp 1 -cpu max,-clflushopt,-clwb This isn't a KVM bug because of the virtualization hole. And really, the test itself is bogus when running on KVM precisely because of said hole (similar holes exist for all the other instructions in the test). The test appears to have been added for QEMU's TCG, which makes sense as there shouldn't be any virtualization holes in a pure emulation environment. That said, it is interesting that the test is suddenly failing, as it means something is buggy. If you can run commands on the host, check for host support via /proc/cpuinfo. If those come back negative (no support), then it would appear that hardware or the host kernel is in a bad/unexpected state. grep -q clflushopt /proc/cpuinfo grep -q clwb /proc/cpuinfo