Received-SPF: pass (google.com: domain of linux-kernel+bounces-82672-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 27 Feb 2024 10:50:39 +0700
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Cc: seanjc@google.com, michael.roth@amd.com, aik@amd.com
Subject: Re: [PATCH v3 00/15] KVM: SEV: allow customizing VMSA features
Message-ID: <Zd1cDyyx65J1IVK1@archie.me>
References: <20240226190344.787149-1-pbonzini@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ctgGmvIrBhMujgO2"
Content-Disposition: inline
In-Reply-To: <20240226190344.787149-1-pbonzini@redhat.com>


--ctgGmvIrBhMujgO2
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 26, 2024 at 02:03:29PM -0500, Paolo Bonzini wrote:
> The idea that no parameter would ever be necessary when enabling SEV or
> SEV-ES for a VM was decidedly optimistic.  The first source of variability
> that was encountered is the desired set of VMSA features, as that affects
> the measurement of the VM's initial state and cannot be changed
> arbitrarily by the hypervisor.
>=20
> This series adds all the APIs that are needed to customize the features,
> with room for future enhancements:
>=20
> - a new /dev/kvm device attribute to retrieve the set of supported
>   features (right now, only debug swap)
>=20
> - a new sub-operation for KVM_MEM_ENCRYPT_OP that can take a struct,
>   replacing the existing KVM_SEV_INIT and KVM_SEV_ES_INIT
>=20
> It then puts the new op to work by including the VMSA features as a field
> of the The existing KVM_SEV_INIT and KVM_SEV_ES_INIT use the full set of
> supported VMSA features for backwards compatibility; but I am considering
> also making them use zero as the feature mask, and will gladly adjust the
> patches if so requested.
>=20
> In order to avoid creating *two* new KVM_MEM_ENCRYPT_OPs, I decided that
> I could as well make SEV and SEV-ES use VM types.  And then, why not make
> a SEV-ES VM, when created with the new VM type instead of KVM_SEV_ES_INIT,
> reject KVM_GET_REGS/KVM_SET_REGS and friends on the vCPU file descriptor
> once the VMSA has been encrypted...  Which is how the API should have
> always behaved.
>=20
> The series is structured as follows:
>=20
> - patches 1 to 5 are unrelated fixes and improvements for the SEV code
>   and documentation.  In particular they change sev.c so that it is
>   compiled only if SEV is enabled in kconfig
>=20
> - patches 6 to 8 introduce the new device attribute to retrieve supported
>   VMSA features
>=20
> - patch 9 disables DEBUG_SWAP by default
>=20
> - patches 10 and 11 introduce new infrastructure for VM types, replacing
>   the similar code in the TDX patches
>=20
> - patches 12 to 14 introduce the new VM types for SEV and
>   SEV-ES, and KVM_SEV_INIT2 as a new sub-operation for KVM_MEM_ENCRYPT_OP.
>=20
> - patch 15 tests the new ioctl.
>=20
> The idea is that SEV SNP will only ever support KVM_SEV_INIT2.  I have
> patches in progress for QEMU to support this new API.
>=20
> Thanks,
>=20
> Paolo
>=20
>=20
> v2->v3:
> - use u64_to_user_addr()
> - Compile sev.c if and only if CONFIG_KVM_AMD_SEV=3Dy
> - remove double signoffs
> - rebase on top of kvm-x86/next

I can't apply this series on top of current kvm-x86/next. On what exact
commit the series is based on?

Confused...

--=20
An old man doll... just what I always wanted! - Clara

--ctgGmvIrBhMujgO2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZd1cCgAKCRD2uYlJVVFO
o8QBAQCptoaVJ0SmzzkqHRaW356Dx1h9Iza0opgqKEbujzlO4QD8Dld0M8ntPrRN
x75LqpsznWKX3Atx8foF3HNqwE9vgwQ=
=Xixn
-----END PGP SIGNATURE-----

--ctgGmvIrBhMujgO2--