Received-SPF: pass (google.com: domain of linux-kernel+bounces-131345-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240318233352.2728327-1-pbonzini@redhat.com> <20240318233352.2728327-10-pbonzini@redhat.com>
 <20240324233918.25tsnexp3rlnhtaa@amd.com>
In-Reply-To: <20240324233918.25tsnexp3rlnhtaa@amd.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu, 4 Apr 2024 13:53:22 +0200
Message-ID: <CABgObfa3UQd7LqWh0SYgFjxCtKiq64yHycw7LEu1h_1F0=Q4Xw@mail.gmail.com>
Subject: Re: [PATCH v4 09/15] KVM: SEV: sync FPU and AVX state at
 LAUNCH_UPDATE_VMSA time
To: Michael Roth <michael.roth@amd.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, 
	isaku.yamahata@intel.com, seanjc@google.com, 
	Dave Hansen <dave.hansen@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 25, 2024 at 12:43=E2=80=AFAM Michael Roth <michael.roth@amd.com=
> wrote:
> There may have be userspaces that previously relied on KVM_SET_XSAVE
> being silently ignored when calculating the expected VMSA measurement.
> Granted, that's sort of buggy behavior on the part of userspace, but QEMU
> for instance does this. In that case, it just so happens that QEMU's rese=
t
> values don't appear to affect the VMSA measurement/contents, but there ma=
y
> be userspaces where it would.
>
> To avoid this, and have parity with the other interfaces where the new
> behavior is gated on the new vm_type/KVM_SEV_INIT2 stuff (via
> has_protected_state), maybe should limited XSAVE/FPU sync'ing to
> has_protected_state as well?

Yes, in particular I am kinda surprised that MXCSR (whose default
value after reset is 0x1F80) does not affect the measurement.

Paolo