From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (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 BDD5430DD00 for ; Tue, 19 Aug 2025 17:50:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755625838; cv=none; b=PRqsnK4WkhAvtFMkPiWDQhjMAzJGZ/TJ13qC+BlFHog3z4/Pb1mavcY/mOH8LgH67tF5rAua6CLdE3GpND/km4lpgDcJqdnLrkFc4foshpCG54A53ZkD56gzR894APLX98cE4kXlrPjKwW+Cp0VO66JGCv+VfQ7omky8+gJYUo8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755625838; c=relaxed/simple; bh=6kzBVQ4vXJ41E2BlAb/8JsyibyENW87RCVv7GZNAxNo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=WsvYG77U6imDy+QninpEZ3aD3Tb6pqvWPeX9CB/cVmoDXnB0ml/MWzQciu0zUxN2NyNFm9lxqc9bKwdZRU3+4zuf9s1asfmrFaBphthG9Smtnrs/qd68lLA785ZKesBAvQ//8gTlf2S6eQabl0996d1mCLCiOvCy/FftpO9vdBo= 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=oDkytkmD; arc=none smtp.client-ip=209.85.215.202 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="oDkytkmD" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b471737e673so10446395a12.1 for ; Tue, 19 Aug 2025 10:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1755625835; x=1756230635; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=wD94oAmVvbxMhzCidjRkeh+Tz5s81LRUlXLzhaycj4k=; b=oDkytkmDbw2b4qUnuqnHtfjisE/qJJvQ3gLhqsVhcIgaRRGgM66DeAHV0D89z2bpp/ 1/JNDP9qbVLfIxtPbOtrIhCRV5zNuGpCqUw2A8jNMyOaqIQ07IOOfx/5TpsNspY93UF9 QlbQ1Wh438BI2HJZkFsDqyAz3hHguhJ+OLctYZ+DK8ram88dH17pba40mRWO+qvDzmuG EZxEU3DCNllG4dzUsa43ZnbZt7+DtsA1bhuhP69JKxZgp350kDL/gvW6xhDUitEYHHYy uqj/9nXQO0QihQEd3Rm+NcFpvmkhZUNEzeSZcybikHyTqft/+GRayfjtyRgO/IQnLfCx TJ9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755625835; x=1756230635; h=content-transfer-encoding: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=wD94oAmVvbxMhzCidjRkeh+Tz5s81LRUlXLzhaycj4k=; b=s7n2LLFpoQm2WFeBNFU42S5TXyTk5WlmQOhBNy1coNqyiicq5E9I7vaIcZJ+e6zmLJ TdlWazC6wKVLWi3At9FXrKRO++nxzAcKzeATgRnI2BwUobCN+RoiYFu9gXfx1Tn1pN/n 3dyUKahFHgYeMasv+HrKqm1iEScSl+Fohjl6lWRVQFWwXl+t9yiLSnWWlhzbZgGhMhmU 2tfmdckA5nillYeTv6eKvHdIIUBsAwuRNKjTbbZPLqR8C2dc4ahUimHJYKZb7I9gWJw7 gAmvYpwZ2/6cVtbNaA7a1Ie90B3J9BHoMBM7A4UDBthBY/lBVbrOv7v4llUV1hPeECLO MRrg== X-Forwarded-Encrypted: i=1; AJvYcCUQqKB2Vg3jocrQ6LT4QEawhMDZtKRBkFVhzpIuXKaCBx9WTSjAZM4vgfEZzICy/pOUNYX5KLt+sDQRksE=@vger.kernel.org X-Gm-Message-State: AOJu0YyZ89Qo/X9t8sIGwr9tQSMxmfGWUWPm4cMK9FGvgtIZCfWX7kmx uP2f4gSmELbrH/BIRrgEE9NjOYWkY1udnkzEhVE4xOIQGc6pwm28abbJUPpLClbBUrCTm5OShgF WYPnFyw== X-Google-Smtp-Source: AGHT+IEkbW0dw54TwTbKnMcxm9LW7g6jyFzY4cJM9GTd67rVA/NTRpaCDoJ8j5GeClUybRMQqkMxlZXyMOs= X-Received: from pggh17.prod.google.com ([2002:a63:c011:0:b0:b42:2b46:da9d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:99a4:b0:232:4d23:439c with SMTP id adf61e73a8af0-2431b7fb1a3mr330582637.26.1755625835023; Tue, 19 Aug 2025 10:50:35 -0700 (PDT) Date: Tue, 19 Aug 2025 10:50:33 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250812025606.74625-1-chao.gao@intel.com> <20250812025606.74625-16-chao.gao@intel.com> Message-ID: Subject: Re: [PATCH v12 15/24] KVM: VMX: Emulate read and write to CET MSRs From: Sean Christopherson To: Rick P Edgecombe Cc: Chao Gao , Weijiang Yang , "mingo@redhat.com" , "x86@kernel.org" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "hpa@zytor.com" , "john.allen@amd.com" , "linux-kernel@vger.kernel.org" , "minipli@grsecurity.net" , "tglx@linutronix.de" , "pbonzini@redhat.com" , "kvm@vger.kernel.org" , "xin@zytor.com" , "mlevitsk@redhat.com" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 19, 2025, Rick P Edgecombe wrote: > On Tue, 2025-08-19 at 09:09 -0700, Sean Christopherson wrote: > > This emulation is wrong (in no small part because the architecture suck= s).=C2=A0 From > > the SDM: > >=20 > > =C2=A0 If the processor does not support Intel 64 architecture, these f= ields have only > > =C2=A0 32 bits; bits 63:32 of the MSRs are reserved. > >=20 > > =C2=A0 On processors that support Intel 64 architecture this value cann= ot represent a > > =C2=A0 non-canonical address. > >=20 > > =C2=A0 In protected mode, only 31:0 are loaded. > >=20 > > That means KVM needs to drop bits 63:32 if the vCPU doesn't have LM or = if the vCPU > > isn't in 64-bit mode.=C2=A0 The last one is especially frustrating, bec= ause software > > can still get a 64-bit value into the MSRs while running in protected, = e.g. by > > switching to 64-bit mode, doing WRMSRs, then switching back to 32-bit m= ode. > >=20 > > But, there's probably no point in actually trying to correctly emulate/= virtualize > > the Protected Mode behavior, because the MSRs can be written via XRSTOR= , and to > > close that hole KVM would need to trap-and-emulate XRSTOR.=C2=A0 No tha= nks. > >=20 > > Unless someone has a better idea, I'm inclined to take an erratum for t= his, i.e. > > just sweep it under the rug. >=20 > Sounds ok to me. All I could think would be something like use the CR/EFE= R > interceptions and just exit to userspace if (CR0.PE && !EFER.LM && CR4.CE= T). But > this would require some rototilling and then likely remain un-exercised. And a far worse experience if a guest did ever trip that combo. Letting th= e guest set bits 63:32 would only cause problems if the guest is being deliberately= weird, whereas exiting to userspace would terminate even well-behaved guests (thou= gh as you note, the odds of a 32-bit guest using CET is quite small...). > Not sure it's worth it.