From nobody Tue Dec 16 21:34:44 2025 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 12EC4E7F14F for ; Thu, 28 Sep 2023 00:20:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229991AbjI1AUR (ORCPT ); Wed, 27 Sep 2023 20:20:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229920AbjI1AUJ (ORCPT ); Wed, 27 Sep 2023 20:20:09 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48519F9 for ; Wed, 27 Sep 2023 17:20:08 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-59f61a639b9so177066147b3.1 for ; Wed, 27 Sep 2023 17:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695860407; x=1696465207; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=TVfUpdVb4H8djihj2XvGyhzWBuel7qP+7Sh6W+PqBNQ=; b=QfVgvl64c9mB0oYD9auDZK0joTr4LN9z9qsgMRTS7qJ0IC2VsIPjYeAgFMTE01lJY/ DxpA8VZAHOwZ9JOjXpQ/YT5jeTrG1M0fSuteVmJ4qdpmMk4qP6qALPkj9wzGkl2K6xsQ pxS38FE0eQLZXb4yWwyA7lDxje892UwNW69m9XO+0uWhRkK73QCJ5e3GC/JYqQocz83W s+m6uPz/z2O7ySSS6PFoTcBCMjZEfr1mRVm5mDz/U+MkNJ7C9ZW0zDCuybGuPKOh0qge 7PbNWxMWccE9/TywCKwoteEZktK20LESCqNlXLhZ361Fom+rbhC4Gyl9UmzyiFU+75+Q SgHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695860407; x=1696465207; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TVfUpdVb4H8djihj2XvGyhzWBuel7qP+7Sh6W+PqBNQ=; b=alB3S7ros2jmiCikW/oZaOjEYryj6THLwp8Tsm61DY4im6jNZPJeO4u83gn+r5rD+k qzMsjpYJZrAAh2Ol5Wn3J9XKPXnxtZxetIbhqtyROTNqSnyOrmz3EkVvQQzk1hnIN/b1 Th4AwDYRXdeBfIeWpB/QD3dKjUI30G+jJEVTsuoUVot8bHsXIXbhWvuBu78FeCBSc5fH tX41Gar1x5nLro3a9RUI7jLmEjp2ReUc39Y3QMuIEP+MF7/Orq3aoaKqJWxrUods6pHf ugj4Ddo0p81XmG1/k9cba9nR1MvY8Ge6sLfZ+p0RZUz2zOP+L5YyVWHcBsfr6VTEPi8p W4Ew== X-Gm-Message-State: AOJu0YwoO6jVbx7f9Io9EEJ0+nxJ+2n46V5Ox0BEyzz3IHmVz1GOMjqC kqF7BLT2p9y6MsqdsMEZpnlRepR7fTo= X-Google-Smtp-Source: AGHT+IFhAUt+8/byCgo6N2PCf+dvWKMyFGUjD1tcqW/1QA0MnF0S/CYub5vkgi5QAlFkH9KMWwwIy4ogT3A= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:541:b0:d0c:c83b:94ed with SMTP id z1-20020a056902054100b00d0cc83b94edmr49229ybs.10.1695860407456; Wed, 27 Sep 2023 17:20:07 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 27 Sep 2023 17:19:55 -0700 In-Reply-To: <20230928001956.924301-1-seanjc@google.com> Mime-Version: 1.0 References: <20230928001956.924301-1-seanjc@google.com> X-Mailer: git-send-email 2.42.0.582.g8ccd20d70d-goog Message-ID: <20230928001956.924301-5-seanjc@google.com> Subject: [PATCH 4/5] KVM: selftests: Load XSAVE state into untouched vCPU during state test From: Sean Christopherson To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Sean Christopherson , Paolo Bonzini , Shuah Khan , Nathan Chancellor , Nick Desaulniers Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, llvm@lists.linux.dev, Tyler Stachecki , Leonardo Bras Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Expand x86's state test to load XSAVE state into a "dummy" vCPU prior to KVM_SET_CPUID2, and again with an empty guest CPUID model. Except for off-by-default features, i.e. AMX, KVM's ABI for KVM_SET_XSAVE is that userspace is allowed to load xfeatures so long as they are supported by the host. This is a regression test for a combination of KVM bugs where the state saved by KVM_GET_XSAVE{2} could not be loaded via KVM_SET_XSAVE if the saved xstate_bv would load guest-unsupported xfeatures. Signed-off-by: Sean Christopherson --- .../testing/selftests/kvm/x86_64/state_test.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kvm/x86_64/state_test.c b/tools/testin= g/selftests/kvm/x86_64/state_test.c index df3e93df4343..115b2cdf9279 100644 --- a/tools/testing/selftests/kvm/x86_64/state_test.c +++ b/tools/testing/selftests/kvm/x86_64/state_test.c @@ -231,9 +231,9 @@ static void __attribute__((__flatten__)) guest_code(voi= d *arg) int main(int argc, char *argv[]) { vm_vaddr_t nested_gva =3D 0; - + struct kvm_cpuid2 empty_cpuid =3D {}; struct kvm_regs regs1, regs2; - struct kvm_vcpu *vcpu; + struct kvm_vcpu *vcpu, *vcpuN; struct kvm_vm *vm; struct kvm_x86_state *state; struct ucall uc; @@ -286,6 +286,21 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu =3D vm_recreate_with_one_vcpu(vm); vcpu_load_state(vcpu, state); + + /* + * Restore XSAVE state in a dummy vCPU, first without doing + * KVM_SET_CPUID2, and then with an empty guest CPUID. Except + * for off-by-default xfeatures, e.g. AMX, KVM is supposed to + * allow KVM_SET_XSAVE regardless of guest CPUID. Manually + * load only XSAVE state, MSRs in particular have a much more + * convoluted ABI. + */ + vcpuN =3D __vm_vcpu_add(vm, vcpu->id + 1); + vcpu_xsave_set(vcpuN, state->xsave); + + vcpu_init_cpuid(vcpuN, &empty_cpuid); + vcpu_xsave_set(vcpuN, state->xsave); + kvm_x86_state_cleanup(state); =20 memset(®s2, 0, sizeof(regs2)); --=20 2.42.0.582.g8ccd20d70d-goog