From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.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 B636C2253EC for ; Tue, 14 Apr 2026 15:42:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776181358; cv=none; b=n8nfWELUWnJdziiw37kUAloKjauvpW0LTHdlPtPliW4cr8eNxk7Kv0cz9DA617pLwoDMqJueeZEi/o62V0ttb5tAsE3hLL1Xnjkuulh2xNW/22+bxjkt2EWYG0bYmz1oHVHlA7+DlmwEdxuR+xxEB/EGygvZoGIiq1FNSzSopQc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776181358; c=relaxed/simple; bh=d85uZONoPFYoyhHBTP/5AhOjoJ1nqGGLyStv6g8XHvU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=u8jQ0oX7YFDCy8NR4YzX4DH/fo5t8txYWefZ1PxhExQmcQCyvk34H8bQTBWP4JUI9Jl7duhiHgrQ83LGAXgsTk2Yzxkde1y1889iJsVS2eXtIcnY/bqpLzRf+8DdOWU51S3JfE38yLj0waGljtuWphDIlSs4zGn1LNLSF2pbtG4= 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=EOahAm00; arc=none smtp.client-ip=209.85.215.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="EOahAm00" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-bce224720d8so3100222a12.1 for ; Tue, 14 Apr 2026 08:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776181357; x=1776786157; 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=CU1ukJvg9ZrAJq3bDmKLyZtYd2mUofGAeeHs08e5UJ0=; b=EOahAm00gQ7c57vw6ZH8u3Kp51gRuwFuoHAg9gk9WDrtfPEdMqad0NaIfcI79rOgQc IwFTXppZqK5FcRfsD867mrxaapMJC8ZdnDCAfDN5slVi8944kpGYQOMPJlRcUZhgB4A3 exXKUMSN+pY1QXTS7hHiNoiY+800XRq6OBPWy8ah4shAO4oo5FDAiGUS84HUzVevP/ua 61jHYTVgAKkT7WfodgGfn1nsNPv5U5fllnUpAblll00yCuTjrGG7ndRs7aMfdAndbzmx b+4mNJfUuc5B/NokDqEAa7LSffu18mpEu9788liEWq1N6vG5Cxo6Feje6tC3BOxal/8J aaXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776181357; x=1776786157; 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=CU1ukJvg9ZrAJq3bDmKLyZtYd2mUofGAeeHs08e5UJ0=; b=HiiS+VnQ6OK4ed09zEk+rKqa492PXVysE9iay6zJmGgZ0hi85dtdVVnJosNXj/ZxLo 8VbJqJFQvAx+eCYSwifxBkTAY4Z51sAexydh7o8C59tOFto4VM5OecX9PKY251Uxk6HM QF6v/JkyypfgG2H3FPLTi7oujAZcGZT8NBAI815HVNm3CxRh7z9TXACHIdKrlHe4x4LR aODs4H3zNspaf459r7DaTqmzNwrYRNHRYr4zm/z23TH2US1Rux2cGMIiPdYAcyn1BJL0 mr7hr8bWC8jq+1D5ynO94qwoe6VxCS9KBA5KXOsOiiFze4kMpqHGB27DjdfpGANfYuj7 bBUg== X-Forwarded-Encrypted: i=1; AFNElJ8KeMrLCMWFc0cBQjaeRilbsbXCSOIWBp8lGrX0GfQhdrcBjQzmbX1hhrpAsvdDgjQCVPz1B9E7FTKO7Xs=@vger.kernel.org X-Gm-Message-State: AOJu0YzpWFKlW2c4pKWGLMk8k4X1/EvS5uIzUoPT/VLu4+FGj1hY8Whk KELs5tPPlxsBl9DlSTPMUXRfuAf/eZj5iOiLxm/bdMdqOV/sqEkLSbqOSDwGffSQQ6xu2O0avja YzyfaKA== X-Received: from pgfw21.prod.google.com ([2002:a63:c115:0:b0:c6d:c043:2cb4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:4305:b0:39f:5c38:8cf9 with SMTP id adf61e73a8af0-39fe4033ed6mr20923797637.40.1776181356884; Tue, 14 Apr 2026 08:42:36 -0700 (PDT) Date: Tue, 14 Apr 2026 08:42:25 -0700 In-Reply-To: <04265eaad625a7e594f1f1b273cfde3c90b84934.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-8-seanjc@google.com> <04265eaad625a7e594f1f1b273cfde3c90b84934.camel@intel.com> Message-ID: Subject: Re: [PATCH 07/11] KVM: x86: Add mode-aware versions of kvm__{read,write}() helpers From: Sean Christopherson To: Kai Huang Cc: "pbonzini@redhat.com" , "vkuznets@redhat.com" , "dwmw2@infradead.org" , "paul@xen.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "yosry@kernel.org" Content-Type: text/plain; charset="us-ascii" On Tue, Apr 14, 2026, Kai Huang wrote: > > > --- a/arch/x86/kvm/svm/nested.c > > +++ b/arch/x86/kvm/svm/nested.c > > @@ -757,7 +757,7 @@ static void nested_vmcb02_prepare_save(struct vcpu_svm *svm) > > > > svm->vcpu.arch.cr2 = save->cr2; > > > > - kvm_rax_write(vcpu, save->rax); > > + kvm_rax_write_raw(vcpu, save->rax); > > kvm_rsp_write(vcpu, save->rsp); > > kvm_rip_write(vcpu, save->rip); > > > > @@ -1238,7 +1238,7 @@ static int nested_svm_vmexit_update_vmcb12(struct kvm_vcpu *vcpu) > > vmcb12->save.rflags = kvm_get_rflags(vcpu); > > vmcb12->save.rip = kvm_rip_read(vcpu); > > vmcb12->save.rsp = kvm_rsp_read(vcpu); > > - vmcb12->save.rax = kvm_rax_read(vcpu); > > + vmcb12->save.rax = kvm_rax_read_raw(vcpu); > > Not sure whether it matters, I think there's an inconsistency here: > > The "rax" one has "raw" postfix, but "rsp" doesn't, despite in practice it > is also a "raw" operation. Ditto for "rip", although it will be moved out > of the "regs[]" GPR array. Oh, there's very much an inconsistency. RIP probably "fine", as it should be impossible to get a 64-bit RIP into the CPU when it's not in 64-bit mode. RSP is likely not "fine", i.e. should probably use a "raw" version. But most importantly, for this patch, I want to avoid introducing functional changes, which means using the "raw" variant to read RAX. > But maybe they are different? > > [...] > > > case EXIT_REASON_MSR_WRITE: > > - kvm_rcx_write(vcpu, tdx->vp_enter_args.r12); > > - kvm_rax_write(vcpu, tdx->vp_enter_args.r13 & -1u); > > - kvm_rdx_write(vcpu, tdx->vp_enter_args.r13 >> 32); > > + kvm_ecx_write(vcpu, tdx->vp_enter_args.r12); > > + kvm_eax_write(vcpu, tdx->vp_enter_args.r13 & -1u); > > Nit: the "& -1u" isn't needed anymore with using kvm_eax_write(), but maybe > we should just focus on replacing the functions in this patch but leave > cleanup in the future. Gah, good eyeballs. I intended to drop it here. > [...] > > > > @@ -12184,23 +12185,23 @@ static void __set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs) > > vcpu->arch.emulate_regs_need_sync_from_vcpu = true; > > vcpu->arch.emulate_regs_need_sync_to_vcpu = false; > > > > - kvm_rax_write(vcpu, regs->rax); > > - kvm_rbx_write(vcpu, regs->rbx); > > - kvm_rcx_write(vcpu, regs->rcx); > > - kvm_rdx_write(vcpu, regs->rdx); > > - kvm_rsi_write(vcpu, regs->rsi); > > - kvm_rdi_write(vcpu, regs->rdi); > > + kvm_rax_write_raw(vcpu, regs->rax); > > + kvm_rbx_write_raw(vcpu, regs->rbx); > > + kvm_rcx_write_raw(vcpu, regs->rcx); > > + kvm_rdx_write_raw(vcpu, regs->rdx); > > + kvm_rsi_write_raw(vcpu, regs->rsi); > > + kvm_rdi_write_raw(vcpu, regs->rdi); > > kvm_rsp_write(vcpu, regs->rsp); > > - kvm_rbp_write(vcpu, regs->rbp); > > + kvm_rbp_write_raw(vcpu, regs->rbp); > > > > Ditto, the "rsp" one stands out. :-) Yeah, same thing as above. I don't think the currently code is 100% correct, but in practice it probably doesn't matter. If we want to clean up RSP handling, it should definitely be done in a separate patch (or patches, plural). But I'm hesitant to even try, especially for this path since it's very much part of KVM's ABI. I.e. if ain't broke, don't fix it. > > [...] > > > +static __always_inline void kvm_e##lname##_write(struct kvm_vcpu *vcpu, u32 val) \ > > It seems tab is used before the 'u32 val'. Seems no need.