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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD0B5C433F5 for ; Mon, 18 Oct 2021 19:31:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C98A260E90 for ; Mon, 18 Oct 2021 19:31:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233772AbhJRTdl (ORCPT ); Mon, 18 Oct 2021 15:33:41 -0400 Received: from mail.skyhub.de ([5.9.137.197]:38412 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233664AbhJRTdb (ORCPT ); Mon, 18 Oct 2021 15:33:31 -0400 Received: from zn.tnic (p200300ec2f085700af6a7a3215758573.dip0.t-ipconnect.de [IPv6:2003:ec:2f08:5700:af6a:7a32:1575:8573]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 2B0B41EC04A9; Mon, 18 Oct 2021 21:31:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1634585479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=+nsWWqmqSGVwOQE+JOrowpz/RZu30zxbCfysGoaRocY=; b=AEy/cLfrJofq6e20RF5dDlNHxet/AbvG36qGdU/gkziMRPWYRmUgWpWnip/LLdTtmpciPR PglnkOoc8OsryDpRzkUPM0NaMJVY2jId2RymJZw1YEnxCCo0xbARdhtgl8M8xJ+lm/9xpH MB12xABMXDNGjuYxsj9xYWJ3S6v9Wy8= Date: Mon, 18 Oct 2021 21:31:19 +0200 From: Borislav Petkov To: "H. Peter Anvin" Cc: Jane Malalane , LKML , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Pu Wen , Paolo Bonzini , Sean Christopherson , Peter Zijlstra , Andrew Cooper , Yazen Ghannam , Brijesh Singh , Huang Rui , Andy Lutomirski , Kim Phillips , stable@vger.kernel.org Subject: Re: [PATCH v2] x86/cpu: Fix migration safety with X86_BUG_NULL_SEL Message-ID: References: <20211013142230.10129-1-jane.malalane@citrix.com> <35CA4584-4CFD-4E47-9825-6438D9ED4ECC@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <35CA4584-4CFD-4E47-9825-6438D9ED4ECC@zytor.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 18, 2021 at 12:10:20PM -0700, H. Peter Anvin wrote: > AFAIK no Intel CPU has ever had that behavior, and always cleared the > segments; I don't Intel has any plans of supporting such a CPUID bit > (although I'd certainly be willing to take such a request back to the > CPU teams on request.) No need - we can always set or clear a flag on Intel, depending on what we do. > That being said, this sounds like an ideal use for the hypervisor CPU > feature flag. Yap, it uses it. > Maybe we should consider a migration hypervisor flag too to explicitly > tell the kernel not to rely on hardware probing that breaks migration > in general. Meh, migration-specific flag calls for all kinds of nasty when each HV would want different things to happen in the guest, for migration. And then the patch flood will come. I mean, we already do a bunch of X86_FEATURE_HYPERVISOR all over the place and apparently it is enough here too... > Now, with a CPUID but being introduced, the right thing would be to > use the CPUID bit as a feature instead of using a bug flag, and add > whitelisting in the vendor-specific code as applicable. I guess we can flip all that logic checking X86_BUG_NULL_SEG... it sounds like a lot of churn to me, though and I don't see a pressing need for it unless someone is bored and wants to do some kernel patching exercises but whatever... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette