From nobody Sun Jun 28 00:51:01 2026 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 03384C433FE for ; Thu, 17 Feb 2022 05:31:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234231AbiBQFbg (ORCPT ); Thu, 17 Feb 2022 00:31:36 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:42482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbiBQFbe (ORCPT ); Thu, 17 Feb 2022 00:31:34 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0E379243136 for ; Wed, 16 Feb 2022 21:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645075879; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+S8NFXssddbsAeetjWyXbDGSuT3B6JkqWWn56zJM37k=; b=XMF/vt6ya7t3HVTRyWP3d181G/CGpEX4xHDkZMc/DgDYy5cWDauTTPd7jYQF5FX144NkJA KSUoVCX/eJylVYwTSJ79XDwGi/5j+Y/WkaeVLd8etA29TadrnnCTrlDpTqI9/SYNjKDuVH Thes7J/k9Xp3gKnPRxJLbJJCxjdBz7o= Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-519-gpb3CtywOw-kumkWe_tq_w-1; Thu, 17 Feb 2022 00:31:17 -0500 X-MC-Unique: gpb3CtywOw-kumkWe_tq_w-1 Received: by mail-ot1-f69.google.com with SMTP id w9-20020a056830410900b005ad1bf1f0b9so17409ott.4 for ; Wed, 16 Feb 2022 21:31:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+S8NFXssddbsAeetjWyXbDGSuT3B6JkqWWn56zJM37k=; b=N3vMdE/BHqT4fCvWceHir64LrRJlaOl6xhV7oRMmN5Sr9BAlLSJKr2ZN86NZTgk6zk rzp6RcwyAIeXg7Df7wFMDEiOid6SN48xqX0Lggx3NkJR860+1O442gRh5uAfoE7UC6Tx Z8Tq4CsTkc2zV2f0hjcsCjbPHJmW1fUYVvkSYUQaoS7JdRC19KpTm/7Q8UIGnu1ljzm/ 9+7o/cbOCm//tUKtCIZFNQ9iPN7dOzX0Bv6Fwb9BYmx++0gbbhJxUvMc5U1DBVA61bZ5 7qKOcaJVbIQ3DFZf+vFoAK6A3hRYG1osl4ePT51KINtCMwyvtLxp1z9jhFEgVj5VabMA dz8w== X-Gm-Message-State: AOAM531ZCjCvZWkuijXONdDIxn3lv0OgpnZkFHdbIHgFKTgexXUrfkZ+ lOTR6B7azaX/TOPG4T16h/W9JVCpcfO3gzSQX2nxh/NWOjiaHhXGPqSyoSEJks2Cxn7aoa6U6+P Sw2wcqP5Dle+JDE1eg8b8M65d X-Received: by 2002:a05:6808:2208:b0:2d3:5181:44a7 with SMTP id bd8-20020a056808220800b002d3518144a7mr2049000oib.201.1645075877045; Wed, 16 Feb 2022 21:31:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJypATkApCAZFKg7P+NajSA5dJuQsvGJ0jKhojrg7tL8lVsKiiizKsfuEgaVzuav2Mw5l075hg== X-Received: by 2002:a05:6808:2208:b0:2d3:5181:44a7 with SMTP id bd8-20020a056808220800b002d3518144a7mr2048996oib.201.1645075876797; Wed, 16 Feb 2022 21:31:16 -0800 (PST) Received: from LeoBras.redhat.com ([2804:431:c7f1:c12c:38a3:24a6:f679:3afd]) by smtp.gmail.com with ESMTPSA id cm18sm8571688oab.7.2022.02.16.21.31.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 21:31:15 -0800 (PST) From: Leonardo Bras To: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , "Chang S. Bae" , Andy Lutomirski , David Gilbert , Peter Xu Cc: Leonardo Bras , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 1/2] x86/kvm/fpu: Mask guest fpstate->xfeatures with guest_supported_xcr0 Date: Thu, 17 Feb 2022 02:30:29 -0300 Message-Id: <20220217053028.96432-2-leobras@redhat.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220217053028.96432-1-leobras@redhat.com> References: <20220217053028.96432-1-leobras@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" During host/guest switch (like in kvm_arch_vcpu_ioctl_run()), the kernel swaps the fpu between host/guest contexts, by using fpu_swap_kvm_fpstate(). When xsave feature is available, the fpu swap is done by: - xsave(s) instruction, with guest's fpstate->xfeatures as mask, is used to store the current state of the fpu registers to a buffer. - xrstor(s) instruction, with (fpu_kernel_cfg.max_features & XFEATURE_MASK_FPSTATE) as mask, is used to put the buffer into fpu regs. For xsave(s) the mask is used to limit what parts of the fpu regs will be copied to the buffer. Likewise on xrstor(s), the mask is used to limit what parts of the fpu regs will be changed. The mask for xsave(s), the guest's fpstate->xfeatures, is defined on kvm_arch_vcpu_create(), which (in summary) sets it to all features supported by the cpu which are enabled on kernel config. This means that xsave(s) will save to guest buffer all the fpu regs contents the cpu has enabled when the guest is paused, even if they are not used. This would not be an issue, if xrstor(s) would also do that. xrstor(s)'s mask for host/guest swap is basically every valid feature contained in kernel config, except XFEATURE_MASK_PKRU. Accordingto kernel src, it is instead switched in switch_to() and flush_thread(). Then, the following happens with a host supporting PKRU starts a guest that does not support it: 1 - Host has XFEATURE_MASK_PKRU set. 1st switch to guest, 2 - xsave(s) fpu regs to host fpustate (buffer has XFEATURE_MASK_PKRU) 3 - xrstor(s) guest fpustate to fpu regs (fpu regs have XFEATURE_MASK_PKRU) 4 - guest runs, then switch back to host, 5 - xsave(s) fpu regs to guest fpstate (buffer now have XFEATURE_MASK_PKRU) 6 - xrstor(s) host fpstate to fpu regs. 7 - kvm_vcpu_ioctl_x86_get_xsave() copy guest fpstate to userspace (with XFEATURE_MASK_PKRU, which should not be supported by guest vcpu) On 5, even though the guest does not support PKRU, it does have the flag set on guest fpstate, which is transferred to userspace via vcpu ioctl KVM_GET_XSAVE. This becomes a problem when the user decides on migrating the above guest to another machine that does not support PKRU: The new host restores guest's fpu regs to as they were before (xrstor(s)), but since the new host don't support PKRU, a general-protection exception ocurs in xrstor(s) and that crashes the guest. This can be solved by making the guest's fpstate->user_xfeatures hold a copy of guest_supported_xcr0. This way, on 7 the only flags copied to userspace will be the ones compatible to guest requirements, and thus there will be no issue during migration. As a bonus, it will also fail if userspace tries to set fpu features that are not compatible to the guest configuration. (KVM_SET_XSAVE ioctl) Also, since kvm_vcpu_after_set_cpuid() now sets fpstate->user_xfeatures, there is not need to set it in kvm_check_cpuid(). So, change fpstate_realloc() so it does not touch fpstate->user_xfeatures if a non-NULL guest_fpu is passed, which is the case when kvm_check_cpuid() calls it. Signed-off-by: Leonardo Bras --- arch/x86/kernel/fpu/xstate.c | 5 ++++- arch/x86/kvm/cpuid.c | 2 ++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 02b3ddaf4f75..7c7824ae7862 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1558,7 +1558,10 @@ static int fpstate_realloc(u64 xfeatures, unsigned i= nt ksize, fpregs_restore_userregs(); =20 newfps->xfeatures =3D curfps->xfeatures | xfeatures; - newfps->user_xfeatures =3D curfps->user_xfeatures | xfeatures; + + if (!guest_fpu) + newfps->user_xfeatures =3D curfps->user_xfeatures | xfeatures; + newfps->xfd =3D curfps->xfd & ~xfeatures; =20 /* Do the final updates within the locked region */ diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 494d4d351859..71125291c578 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -296,6 +296,8 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *v= cpu) vcpu->arch.guest_supported_xcr0 =3D cpuid_get_supported_xcr0(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent= ); =20 + vcpu->arch.guest_fpu.fpstate->user_xfeatures =3D vcpu->arch.guest_support= ed_xcr0; + kvm_update_pv_runtime(vcpu); =20 vcpu->arch.maxphyaddr =3D cpuid_query_maxphyaddr(vcpu); --=20 2.35.1 From nobody Sun Jun 28 00:51:01 2026 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 80BD2C433EF for ; Thu, 17 Feb 2022 05:32:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234312AbiBQFcX (ORCPT ); Thu, 17 Feb 2022 00:32:23 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:44292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234301AbiBQFcU (ORCPT ); Thu, 17 Feb 2022 00:32:20 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E99EBA1BC2 for ; Wed, 16 Feb 2022 21:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645075926; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2ixaC+WveNvHaDkBhw3sVXdx9/WgsexXW9FNcptE03U=; b=TG9h3pRAp1iLNw7rbW2i2S5prYavXzXoc98FHrAzr/KPVoXlTumNq8uTYzD/yFNqTTOR8W 1pI58GiFhSYZG+Zov4vmQipDs6nv3UDIy9nxvcg5pxCh6Xi+t6TOrcBer5XcG158UiL3DT U8kbmu4Opy9QdMGUHjfN1LXsa8YTqck= Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-477-FUzy0dpJOrG-00P97P-avg-1; Thu, 17 Feb 2022 00:31:24 -0500 X-MC-Unique: FUzy0dpJOrG-00P97P-avg-1 Received: by mail-oi1-f199.google.com with SMTP id bb20-20020a056808169400b002cd940d6247so1881660oib.7 for ; Wed, 16 Feb 2022 21:31:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2ixaC+WveNvHaDkBhw3sVXdx9/WgsexXW9FNcptE03U=; b=csiTMHu5Y/K7lm7N/dFuDxzsB6stqAcMP8d0IlK1nzhpXuiD08dFjCtC83KZN6+WDN osiHU4dCKzMqNgKl4natV8MvG6aZvr636azFpw2nTJbWneu9Hw7D401P/TbIWapzwKvk YxMmzkyOPTApV299VltwpG/KZWSmyHFp9Z5Tan0/Qf+a83mm9vsPeHzeFRrCNmXtL7v0 2VmxEY9dfK9hVU8TrjLZGdVg0cV1KzXzQfcFc92l1+/XMDbfL/T5EJlxT7+tGLZMiYEc 2ifyqXRcFYc1uuCwfh2iM00wCKZqekDGBP07RWGES6Tzbq41kfcQzWIX32n2X9oUzRMx 6IZQ== X-Gm-Message-State: AOAM533329bJflRtZC9iXsLHkkpgT1z5QVcRPgci4QWpDaBkzngLNHv0 ixxMQQHy27K+ID//R2dmV1mXj9t+zjmTRf62X3OkN/3zC2PqgiOESsXHfpeaFUS+qnMCQwO/rMR t1veMc9r9SF7fs92dm73/VPYy X-Received: by 2002:a05:6870:a894:b0:d3:cc7:ac28 with SMTP id eb20-20020a056870a89400b000d30cc7ac28mr491733oab.207.1645075883502; Wed, 16 Feb 2022 21:31:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgOyeDMwJ516sad84JIJ6nVrFCyP8MKFMYWt+0bMrbpBDX1hyXK+FtkMWoj/raLhQWyulXow== X-Received: by 2002:a05:6870:a894:b0:d3:cc7:ac28 with SMTP id eb20-20020a056870a89400b000d30cc7ac28mr491718oab.207.1645075883290; Wed, 16 Feb 2022 21:31:23 -0800 (PST) Received: from LeoBras.redhat.com ([2804:431:c7f1:c12c:38a3:24a6:f679:3afd]) by smtp.gmail.com with ESMTPSA id cm18sm8571688oab.7.2022.02.16.21.31.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 21:31:22 -0800 (PST) From: Leonardo Bras To: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , "Chang S. Bae" , Andy Lutomirski , David Gilbert , Peter Xu Cc: Leonardo Bras , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 2/2] x86/kvm/fpu: Remove kvm_vcpu_arch.guest_supported_xcr0 Date: Thu, 17 Feb 2022 02:30:30 -0300 Message-Id: <20220217053028.96432-3-leobras@redhat.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220217053028.96432-1-leobras@redhat.com> References: <20220217053028.96432-1-leobras@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" kvm_vcpu_arch currently contains the guest supported features in both guest_supported_xcr0 and guest_fpu.fpstate->user_xfeatures field. Currently both fields are set to the same value in kvm_vcpu_after_set_cpuid() and are not changed anywhere else after that. Since it's not good to keep duplicated data, remove guest_supported_xcr0. To keep the code more readable, introduce kvm_guest_supported_xcr() and kvm_guest_supported_xfd() to replace the previous usages of guest_supported_xcr0. Signed-off-by: Leonardo Bras --- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/kvm/cpuid.c | 5 +++-- arch/x86/kvm/x86.c | 20 +++++++++++++++----- 3 files changed, 18 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 6dcccb304775..ec9830d2aabf 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -703,7 +703,6 @@ struct kvm_vcpu_arch { struct fpu_guest guest_fpu; =20 u64 xcr0; - u64 guest_supported_xcr0; =20 struct kvm_pio_request pio; void *pio_data; diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 71125291c578..b8f8d268d058 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -282,6 +282,7 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *v= cpu) { struct kvm_lapic *apic =3D vcpu->arch.apic; struct kvm_cpuid_entry2 *best; + u64 guest_supported_xcr0; =20 best =3D kvm_find_cpuid_entry(vcpu, 1, 0); if (best && apic) { @@ -293,10 +294,10 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu = *vcpu) kvm_apic_set_version(vcpu); } =20 - vcpu->arch.guest_supported_xcr0 =3D + guest_supported_xcr0 =3D cpuid_get_supported_xcr0(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent= ); =20 - vcpu->arch.guest_fpu.fpstate->user_xfeatures =3D vcpu->arch.guest_support= ed_xcr0; + vcpu->arch.guest_fpu.fpstate->user_xfeatures =3D guest_supported_xcr0; =20 kvm_update_pv_runtime(vcpu); =20 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 641044db415d..92177e2ff664 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -984,6 +984,18 @@ void kvm_load_host_xsave_state(struct kvm_vcpu *vcpu) } EXPORT_SYMBOL_GPL(kvm_load_host_xsave_state); =20 +static inline u64 kvm_guest_supported_xcr(struct kvm_vcpu *vcpu) +{ + u64 guest_supported_xcr0 =3D vcpu->arch.guest_fpu.fpstate->user_xfeatures; + + return guest_supported_xcr0; +} + +static inline u64 kvm_guest_supported_xfd(struct kvm_vcpu *vcpu) +{ + return kvm_guest_supported_xcr(vcpu) & XFEATURE_MASK_USER_DYNAMIC; +} + static int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr) { u64 xcr0 =3D xcr; @@ -1003,7 +1015,7 @@ static int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 i= ndex, u64 xcr) * saving. However, xcr0 bit 0 is always set, even if the * emulated CPU does not support XSAVE (see kvm_vcpu_reset()). */ - valid_bits =3D vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FP; + valid_bits =3D kvm_guest_supported_xcr(vcpu) | XFEATURE_MASK_FP; if (xcr0 & ~valid_bits) return 1; =20 @@ -3706,8 +3718,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) !guest_cpuid_has(vcpu, X86_FEATURE_XFD)) return 1; =20 - if (data & ~(XFEATURE_MASK_USER_DYNAMIC & - vcpu->arch.guest_supported_xcr0)) + if (data & ~(kvm_guest_supported_xfd(vcpu))) return 1; =20 fpu_update_guest_xfd(&vcpu->arch.guest_fpu, data); @@ -3717,8 +3728,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) !guest_cpuid_has(vcpu, X86_FEATURE_XFD)) return 1; =20 - if (data & ~(XFEATURE_MASK_USER_DYNAMIC & - vcpu->arch.guest_supported_xcr0)) + if (data & ~(kvm_guest_supported_xfd(vcpu))) return 1; =20 vcpu->arch.guest_fpu.xfd_err =3D data; --=20 2.35.1