From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 0DF6C30C150 for ; Sat, 6 Jun 2026 11:11:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780744318; cv=none; b=dTP8WWUNzAxQY1IYfh3ZvxNcnS0O2f7rHKiZZzzX+nywDc5Yb0PkEqKFxK15T/1dlAQej2pwlQd9fqLHRC0luVi9ckhvSZlHuCxV5/B69qmwmG+ZeHcCSYYJy2Mr6gr0/fCwbJ6qMsyG4tjHDagNKzu3B+Gt0Q0OjJr9EkduYUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780744318; c=relaxed/simple; bh=dvnRGdrRFnRuhci5wez75UUJUTbmRrm2qIUBlXHLVfg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=siyeq3lURMiCZsXK8FBTeXnvocQEw+DFrwuNgLhd/6nkhNq7TOtOaQHLfQWZEL/s97Ejdfw4fY/H1LLa4M0qTYwdBM2gKoFKE/s9uvub7cEEgDszMozzWYpdEDlOb28pKSm3q3ixG+oeD8fN72J5lPoqZcD/JALRJchH5QFLpHA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AkBSva64; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AkBSva64" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-46015dc517aso2272504f8f.2 for ; Sat, 06 Jun 2026 04:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780744315; x=1781349115; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=93u+GJ/ci/dwDHALLFM8eJXF4CRQlugF6cy8CKPz+sU=; b=AkBSva64Obou3QlErdOXcZK8+0ufX+yEIvJWqhXHEsPULXa5j57mpJsBOempeDODfZ B6wwl10BFe/l1Oz0IVzLyE3Lf2Nyelws4NzObllVXGQhZLkgmc36lnigg0Mv7jZ49iGL rnr6zW6JHg/3XfB5pPjrkiN589nK+V9tjKxUQculasv7fbKyjPJS9CfFJVWz/hroe1y6 gjYprr8lIqlEEEM9/CinEXVWJ//zfcqavNUeTEAUUjaIrXG98TezLu8iHvimIkFUCcu6 Sz7iS1+svv9yj5t4ywYShN2nm2H7gwFmrBqvAdxrMHsP0AwFYwI+KHlYJssjsWB2/e6m DPbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780744315; x=1781349115; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=93u+GJ/ci/dwDHALLFM8eJXF4CRQlugF6cy8CKPz+sU=; b=eLpbKtl66B/34eZLxBYa3b4Bu1hoHiOymqh6h2Kded8VS8n/TwnYLCuSMyHE462jRV Sgavp6NqPKhwo+mVXvgJuCU8dTTWsf4G9WPk08YMmVdyE8rx5wVWWN7bXjOL/1kqaOOk FImcmLMq12sbq+GF/8w/0QcpbZ8eiGZWzhfnnnroraKmQUmvi0MoW6BDxSlPqtgV2ipr 7fi0p11MyMTj8/pkJod8KV0bwiikMYuh9VdPSiv5C+Sh1QDq2V27wb6Z4XK8gx6bVQGW UWKMOYZqWHoQN3bbnuOtCIKoOLyIfw3yQLrvkSNBbnVBr8j9tsQ50MvZQUE5/YTFPCEk j9nA== X-Forwarded-Encrypted: i=1; AFNElJ/w7N62+H3kiYxsIMbQ3DtA2OstlmfiQocxaR7PV1Zy6vhC5of6DA9OAB6vwsVov9F843G5Ub0TdZhV1JE=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4Ghm2JpOn6i5rIHWt2lQHT8DUHHh4mLVh3286kbZ0Fktn9ANh yZiKZi5mp75dJQA6/UzDPz4Ehv0IvJowg5egREHiOD5nPy4EDvPsiyHa X-Gm-Gg: Acq92OEHuZKtRN6z4E2oTVrU0xdhllmMpW5ignYuB00aoFmLprIll0pgRohVKb08Lf8 +G2nZH5GlplgcPzItA5pzjRpgWm1qbqkVS6+eIkmxt+YWNR2w+oFGIIBdNbcgHfPi7lDt0L77Ah a+xC9W/Bz09+uRDyJLZd4vPsXE+5f0rieKiAyxCjcMwzjvJyA2qlWbh17lgZazDqYNKP8a1vF0u YsP/lywPbXExA6tWafAlsJmDC7WF1hOb6NMZAzeXBpssZoO8WPx5dd/Kr4ZZGE3RqvOoMprb4IR 6pJ7/ajYxJUbXWg+N9YQ29H8UFhy68dKAFONh4c/q2Jbd9eJY8cHrF97gUdeTqaUdjxyaavSk+d OrmxbXr43r6K6hGAcxpq7dqoLp7dkxymi7Or3Hen+3ORypwxx0asX2CLaWUljAugK80SNMtx5T9 XoTWYUTd2eeGn10jurVDfzAtbZVi2AIcVPmjqfCYiY6WszsTFvvxE1/+5wZUVF2ZZzH/ESwds= X-Received: by 2002:adf:f88c:0:b0:45a:e3dd:586b with SMTP id ffacd0b85a97d-4603063a9e2mr10245115f8f.18.1780744314001; Sat, 06 Jun 2026 04:11:54 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f344541sm31542831f8f.22.2026.06.06.04.11.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 04:11:53 -0700 (PDT) Date: Sat, 6 Jun 2026 12:11:52 +0100 From: David Laight To: David Woodhouse Cc: Sean Christopherson , Paul Durrant , Hyunwoo Kim , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/8] KVM: x86/xen: Introduce kvm_xen_has_64bit_shinfo() macro Message-ID: <20260606121152.5ab6bf09@pumpkin> In-Reply-To: <63c77cb3e7fb8b9b1ee0baa006760d494f16ce54.camel@infradead.org> References: <20260605143034.3603-1-dwmw2@infradead.org> <20260605143034.3603-3-dwmw2@infradead.org> <20260606103043.0d9a4baf@pumpkin> <63c77cb3e7fb8b9b1ee0baa006760d494f16ce54.camel@infradead.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 06 Jun 2026 10:35:45 +0100 David Woodhouse wrote: > On Sat, 2026-06-06 at 10:30 +0100, David Laight wrote: > > On Fri,=C2=A0 5 Jun 2026 15:17:27 +0100 > > David Woodhouse wrote: > > =20 > > > From: David Woodhouse > > >=20 > > > Add a kvm_xen_has_64bit_shinfo() helper macro to replace the repeated > > > pattern of 'IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode' > > > throughout the Xen emulation code. The macro uses READ_ONCE() to > > > ensure a consistent snapshot of the flag, which can be changed by > > > another vCPU at any time. =20 > >=20 > > If another vCPU changes the flag then isn't it all broken? > > The code seems to need the value to be stable. =20 >=20 > Do you believe the explanation in patch 4 to be insufficient? (I read patch 2 first...) Changing the same lines twice is s bit excessive. There is this bit in #4: Even with this fix, the same corruption can occur if 64-bit mode is latched and the guest switches to 32-bit mode immediately afterward. which, I think, means it is all hopeless really. If the structure layout doesn't depend on 32/64 bit then why check (or compile-time check). But if the layout differs and the the mode can change dynamically then you need some kind of locking (or similar). -- David