From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A4D133D4F7 for ; Mon, 5 Jan 2026 17:31:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767634268; cv=none; b=H0+04AsAySftB+rQxflsKWzyKDFUo5vzN4iP8yJpXoQqUDQbixZgqWr7GIGNz/6ExBo4EjKzIiPZyAc/fTGQ6KV49+T74OkNgr/99ovGtuMp8EqNomTgQWm8xX1IQiPcyo57jUynN5aicbpt8oxhKMUhnOEHIVl+5+xunI0Sf8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767634268; c=relaxed/simple; bh=CxZ4OgJGj/k3K59SPvzFQSboJQlhCSm/PlRd8ioDSvI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bPQ5auCZN5xqqGqorKhGIBCJ6jpwOZ0/Di8UL7Po9SZz3Vw8pgCwHos/c4oWk5RsPWIK055/CKuLC7IxU9KO0NEDPQEOE6Sy3vT5Vrx0MFiItTzefneAxBpKRfqeEzPZSchbNLpZL2Oln+UNEhX3QGHECvqpdoJ447gucUGU8fs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=uGfxZdmX; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uGfxZdmX" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-34c48a76e75so638248a91.1 for ; Mon, 05 Jan 2026 09:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767634267; x=1768239067; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=8kSIPJzul/X8QFqPR13PL+AQ9eUnhoQcnkip5GRavHI=; b=uGfxZdmX5TkKJXc+bdE8nuacRkRqvHrMEdWKdHhK0TaF2Jg/N8WbSzDB4qJjzP5SpG yzI4bGE7H4Ara68Z7h7SO5xjFPYLnksdO1k7Qwu0EB8m/laUCCvqhfwzqE5KH0ZGUp/C wWFDjmBs6r/+3WKOTByUl9XPyOMiJ2TkPZckDPEnqujzEp9Rtve8rJRgmBdRShlF09Ee iOn1nTtgZk6EKaoc/eKCc4n2eOO6IMknbsse7Gl7WoYtGVwQLAMWee0sjX6MQiMfn9yj ySyJQJ8k0B5HWdmsvLIsXVsjkprPYlsZabB9qfEfSGtxnahseilxbqeYZOKRj9xm8OJr i/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767634267; x=1768239067; 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=8kSIPJzul/X8QFqPR13PL+AQ9eUnhoQcnkip5GRavHI=; b=X0Hw6/F4nc/v5qm72wjnvdTrEVQ9vGeLxLvz+FheudaeUDSybkIHsoJgLXIZCXYOtA BmtOwv6jGd6ExQsPSWothzQIgwU8csKT5fQU8vRQbg3rJzHbw5WUJK9gs/nsOvlFRHoT T9CD+5iKeQw53tWV2udF/MjoXL4+x/6QOv4AKKPx7qdPnjT8aASCm0DTm689jcFZXu9A DKstQDBkYplGyQ7rvkQgLRC3dHyXeZEIpRJHVTu3ibEA9+9IlUCq50NWJIjrOlNlLBic foFK1U1NFRSIU9338fTC3Ls7GrElkwStfYZGgDl5cVsqVkTRYFEhy5eweP2mlfIpB7RH DaCg== X-Forwarded-Encrypted: i=1; AJvYcCUQ/wO30VvwOgz2Cv8yh75xNWkjcALovSUKYnH7/tg9tmKyLDCFQq1mxLByH+egih+DUBuLS5fFoZSttGA=@vger.kernel.org X-Gm-Message-State: AOJu0Yyx78NKluyhkcCzE4q+HqOk6LMwfdlEISrANtVx1JF487nkD6FT wLdZeBoXQuSKaUZsUFdbHKR41Apo9fToIMDpHBffxz9l6n7JN1ujqJDOXbNe13xGKJjZPUNsa/0 qc/bPQA== X-Google-Smtp-Source: AGHT+IFNFCW51z5uQhSMaKAD/3SNzpI333xLiv4+CS5A7/6N6OYcuHjrQA1qzr3I/rduC2hfHA1d6uzkn6Q= X-Received: from pjok2.prod.google.com ([2002:a17:90a:9102:b0:34a:bcb2:43ba]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3c46:b0:340:5c27:a096 with SMTP id 98e67ed59e1d1-34f5f273bebmr106658a91.6.1767634266701; Mon, 05 Jan 2026 09:31:06 -0800 (PST) Date: Mon, 5 Jan 2026 09:31:05 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260101090516.316883-1-pbonzini@redhat.com> <20260101090516.316883-2-pbonzini@redhat.com> Message-ID: Subject: Re: [PATCH 1/4] x86/fpu: Clear XSTATE_BV[i] in save state whenever XFD[i]=1 From: Sean Christopherson To: Yao Yuan Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Sat, Jan 03, 2026, Yao Yuan wrote: > On Thu, Jan 01, 2026 at 10:05:13AM +0100, Paolo Bonzini wrote: > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > > index da233f20ae6f..166c380b0161 100644 > > --- a/arch/x86/kernel/fpu/core.c > > +++ b/arch/x86/kernel/fpu/core.c > > @@ -319,10 +319,29 @@ EXPORT_SYMBOL_FOR_KVM(fpu_enable_guest_xfd_features); > > #ifdef CONFIG_X86_64 > > void fpu_update_guest_xfd(struct fpu_guest *guest_fpu, u64 xfd) > > { > > + struct fpstate *fpstate = guest_fpu->fpstate; > > + > > fpregs_lock(); > > - guest_fpu->fpstate->xfd = xfd; > > - if (guest_fpu->fpstate->in_use) > > - xfd_update_state(guest_fpu->fpstate); > > + > > + /* > > + * KVM's guest ABI is that setting XFD[i]=1 *can* immediately revert > > + * the save state to initialized. Likewise, KVM_GET_XSAVE does the > > + * same as XSAVE and returns XSTATE_BV[i]=0 whenever XFD[i]=1. > > + * > > + * If the guest's FPU state is in hardware, just update XFD: the XSAVE > > + * in fpu_swap_kvm_fpstate will clear XSTATE_BV[i] whenever XFD[i]=1. > > + * > > + * If however the guest's FPU state is NOT resident in hardware, clear > > + * disabled components in XSTATE_BV now, or a subsequent XRSTOR will > > + * attempt to load disabled components and generate #NM _in the host_. > > + */ > > Hi Sean and Paolo, > > > + if (xfd && test_thread_flag(TIF_NEED_FPU_LOAD)) > > + fpstate->regs.xsave.header.xfeatures &= ~xfd; > > + > > + fpstate->xfd = xfd; > > + if (fpstate->in_use) > > + xfd_update_state(fpstate); > > I see a *small* window that the Host IRQ can happen just after above > TIF_NEED_FPU_LOAD checking, which could set TIF_NEED_FPU_LOAD Only if the code using FPU from IRQ context is buggy. More below. > but w/o clear the xfd from fpstate->regs.xsave.header.xfeatures. > > But there's WARN in in kernel_fpu_begin_mask(): > > WARN_ON_FPU(!irq_fpu_usable()); > > irq_fpu_usable() > { > ... > /* > * In hard interrupt context it's safe when soft interrupts > * are enabled, which means the interrupt did not hit in > * a fpregs_lock()'ed critical region. > */ > return !softirq_count(); > } > > Looks we are relying on this to catch the above *small* window > yet, we're in fpregs_lock() region yet. Kernel use of FPU from (soft) IRQ context is required to check irq_fpu_usable() (e.g. via may_use_simd()), i.e. calling fpregs_lock() protects against the kernel using the FPU and thus setting TIF_NEED_FPU_LOAD. The WARN in kernel_fpu_begin_mask() is purely a sanity check to help detect and debug buggy users.