From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 AB68819539F for ; Thu, 16 Apr 2026 00:27:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776299269; cv=none; b=cXvTzOKus09JAX4MinuNddExfMEYJUgGLNM97N9eLIQlMNblfsjrWyQ9sZmmzfbeTIE8DmdDmAwwDoSD7VQTrX+auB7drzqvaQQDC01bXSPS4JyLttFraFPzrnawCsjU6+CaKyTiCRDwErxurTq9wlD2G9hVGhtjLuHuoh17pss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776299269; c=relaxed/simple; bh=91KI0fJU4Wp82t2FkQOv787CBX84KoNvLOEgpOIXuqY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=avD7fq33HWkO0vc02485QH5C7W0Inm51/Ji1MCwgSxszb2SOwxA2MZdXSX89XA/S6VD2WIR3ftc1Z3InXQlePi2eCg8rGOanu3pOlG7RQWYxc2Ubp0l7YsJAJtvvLbU1PqEZduZiVKVmkSgLmsmLP7PsJWlYTy19nMj3tzodfwM= 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=HlEJmlBn; arc=none smtp.client-ip=209.85.210.201 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="HlEJmlBn" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-8230d6d54a5so54057b3a.1 for ; Wed, 15 Apr 2026 17:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776299268; x=1776904068; 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=aTqHOZA62OG02ouAmiVm2b8T4YwA2WULJcljq4P/wu8=; b=HlEJmlBn8bkl3vcXTbtmQHwf0Rvv5xDM+j5i1xKMYNaKWMDiHwIOqB7mXKYdlPvw1F /ixYcTgQE2bo4gyVleEqnSUkIupbqjzMtzQtUSr9gwBQuCaufWWummn/dpU5QvqKdz0b FnADTR58MfaM6ZmIJRrAQ9CglwfZ56DAC3SwwkHXIzgSV6eNCA28oSWHUHhDd7dGbh+b aunF19em5/y9fD78b/cY6o14d8vdmtBC8Eqnn9kMXDVNeQzih6RKsxxAYf2y8WR0Pul0 +IXWXZpc9hnidjkbACrf/xQIqJ1X4jzUTUNtu6f0Aujq5mYLcxIKjUH0pGuCn1LUQw7M QIww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776299268; x=1776904068; 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=aTqHOZA62OG02ouAmiVm2b8T4YwA2WULJcljq4P/wu8=; b=RiIJmS5Qk+C1bL/7/jH8V0ZpKFxf7OQgQHBp7CfXyW96fvvr0aevcWmES7fOkbDLzD HdUWfjyCZeMR/MKDMgK9tchsT6ZEs809uan/vG41oFKoZAvT6VZVm6ZxtvXZJr2EBTwn N6YgblScwKyNP+RMkL/dCN9FluhxJ3DkO+FOOMfnzun6HeISlL1mSgFLvDk+h9ECipeu vOQJw//txATg3V4Elh/VLEjQCSqEfbweEi/XHXbWH954I3Dmx+TnPwUdvbySqrpOcZ5r AqDgdn45o6d0mnb6NmOVpe4jjvOWMTyPnGz8gDr8TtAG1gZAOMc/amJWHZcCsCq2sY4Z chJg== X-Forwarded-Encrypted: i=1; AFNElJ+9A/rueOPiKW/mZKWNNoI1uMRgqK0mFLLKasju7UNZygO1iLB46YHuNIh3L817M72JryvgPu6WUJJl104=@vger.kernel.org X-Gm-Message-State: AOJu0YxebhSl6ptlUDmZnYTIc3YE0QI0PFjnY52K9CFi9txVsQoVGlGM MXBmsRwrUwg3ETSAZyYjXtgaQZVVAL3HPAfq8yfZS0nmbLYqpjENpYH2Fm8ocFsC+6n30j2GPxy fYKw2Ng== X-Received: from pfgs24.prod.google.com ([2002:a05:6a00:1798:b0:7fb:ed58:5e4b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2191:b0:822:69b2:7ed0 with SMTP id d2e1a72fcca58-82f764130bcmr1195893b3a.6.1776299267782; Wed, 15 Apr 2026 17:27:47 -0700 (PDT) Date: Wed, 15 Apr 2026 17:27:46 -0700 In-Reply-To: <9f4a3dfa2d3fa2a81161652d81585b779a182866.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260409235622.2052730-1-seanjc@google.com> <20260409235622.2052730-5-seanjc@google.com> <9f4a3dfa2d3fa2a81161652d81585b779a182866.camel@intel.com> Message-ID: Subject: Re: [PATCH 04/11] KVM: VMX: Read 32-bit GPR values for ENCLS instructions outside of 64-bit mode From: Sean Christopherson To: Kai Huang Cc: "yosry@kernel.org" , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "dwmw2@infradead.org" , "paul@xen.org" Content-Type: text/plain; charset="us-ascii" On Wed, Apr 15, 2026, Kai Huang wrote: > On Wed, 2026-04-15 at 14:37 -0700, Sean Christopherson wrote: > > On Mon, Apr 13, 2026, Kai Huang wrote: > > But IIRC, that's "just" the architectural behavior. Hardware implementations may > > choose to preserve values. > > That seems to be a violation to a "basic" architecture :-) Not really. The SDM says they aren't guaranteed to be _preserved_. It doesn't say that they will be zeroed. And so literally any value in bits 63:32 is architecturally legal. > > > If vCPU is in 32-bit mode then it should not be able to access 64-bit GPR? > > > > Yes and no. Mostly no. Architecturally, they're all off limits. But, again > > going from memory that's ~15 years old at this point, IIRC the behavior is that > > writes in 32-bit modes zero bits 63:32, same as 32-bit writes in 64-bit mode. > > > > Take all of my memory with a huge grain of salt, it's very possible I'm > > mis-remembering hallway discussions from a long time ago. > > I tend to think it's beyond the point we need to worry about. It shouldn't > happen even the guest is buggy or malicious AFAICT, unless KVM somehow > messes things up itself, in which case a WARN() is more reasonable I > suppose. KVM needs to worry about it from the perspective of not consuming garbage. As above, KVM cannot assume bits 63:32 are zero, and so needs to be careful to only consume bits 31:0. > This also made me look into whether how VMENTER handles GPRs when vCPU is > not in 64-bit mode. I see nothing described in the SDM except VMENTRY > checks "guest's" RIP and RFLAGS. Maybe KVM should explicitly clear high > bits of GPRs when going back to compatible mode from 64-bit mode, or maybe > hardware does it? Definitely not. VM-Exit => VM-Enter must be transparent to the guest. E.g. if a host IRQ arrives, register state shouldn't magically change from the guest's perspective. If hardware clobbers state, so be it. But I don't want KVM to actively clobber registers in this case.