diff --git a/specs/2024.1/approved/amd-sev-es-libvirt-support.rst b/specs/2024.1/approved/amd-sev-es-libvirt-support.rst
new file mode 100644
index 000000000..82fc10793
--- /dev/null
+++ b/specs/2024.1/approved/amd-sev-es-libvirt-support.rst
@@ -0,0 +1,264 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+=======================================================================
+libvirt driver launching instances with memory encryption by AMD SEV-ES
+=======================================================================
+
+https://blueprints.launchpad.net/nova/+spec/amd-sev-es-libvirt-support
+
+This spec proposes work required in order to extend the existing libvirt driver
+feature to launch AMD SEV-encrypted instances, to support also using AMD
+SEV-ES, which is the extended version of AMD SEV, as memory encryption
+mechanism.
+
+Problem description
+===================
+
+Current libvirt driver supports launching instances with memory encryption by
+`AMD's SEV (Secure Encrypted Virtualization) technology
+`_. However the current implementation supports
+only AMD SEV, and does not support new versions. For exmaple SEV-ES also
+encrypts all CPU register contents when a VM stops running, to achieve more
+complete protection of VM data, but users can't leverage these features because
+of this limitation.
+
+.. note::
+ At the time or writing AMD already released CPUs which supports SEV-SNP, but
+ the required hypervisor features to use SEV-SNP are not yet merged into
+ kernel. So in this spec we focus on SEV-ES. We attempt to keep the proposal
+ as much compatiblre as possible, based on the implementations published by
+ AMD.
+
+Use Cases
+---------
+
+#. As a cloud administrator, in order that my users can have more confidence
+ in the security of their running instances, I want to provide a flavor
+ containing the `required trait extra spec
+ `_
+ which will allow users booting instances with that flavor to ensure
+ that their instances run on an SEV-ES-capable compute host with SEV-ES
+ encryption, instead of SEV encryption, enabled.
+
+#. As a cloud user, in order to reduce data leakage risks further, I want to
+ be able to boot VM instances with SEV-ES functionality, instead of SEV
+ functionality, enabled.
+
+Proposed change
+===============
+
+We propose extending the existing implementation to support launching instances
+with SEV functionality.
+
+- Add detection of host SEV-ES capabilities, which checks the following items.
+
+ - The presence of the following XML in the response from a libvirt
+ `virConnectGetDomainCapabilities()
+ `_
+ API call `indicates that both QEMU and the AMD Secure Processor
+ (AMD-SP) support SEV functionality
+ `_::
+
+
+ ...
+
+ ...
+
+ ...
+
+
+
+
+ - ``/sys/module/kvm_amd/parameters/sev_es`` should have the value ``Y``
+ to indicate that the kernel has SEV capabilities enabled. This
+ should be readable by any user (i.e. even non-root).
+
+- Implement a new ``MEM_ENCRYPTION_CONTEXT_V2`` `resource class
+ `_
+ to represent the number of guests with SEV-ES enabled which a compute host
+ can run concurrently. A separate resource class is required because maximum
+ number of SEV-ES guests a compute host can accept is separate from maximum
+ number of SEV guests.
+
+ .. note::
+ SEV and SEV-ES have separate limits of guest numbers, because SEV-ES
+ requires SEV ASID while SEV does not. Maximum ASID should be configured in
+ BIOS (or UEFI) to use SEV-ES. SEV-SNP requires ASID, so is expected to be
+ able to use the same v2 class.
+
+- Add the new ``HW_CPU_AMD_SEV_ES`` trait to os-traits.
+
+- Make the libvirt driver `update the ProviderTree object
+ `_
+ with the correct inventory for the new ``MEM_ENCRYPTION_CONTEXT_V2``
+ resource class.
+
+- Change the libvirt driver to include extra XML in the guest's domain
+ definition when ``resources:MEM_ENCRYPTION_CONTEXT_V2=1`` is present in
+ the flavor extra specs. The extra XML is mostly similar to the one used in
+ SEV, but its guest policy field needs the SEV-ES bit (bit 2) enabled.
+
+- Add support for a new ``hw:mem_encryption_mechanism`` parameter in flavor
+ extra specs, and a new ``hw_mem_encryption_mecnahism`` image property. When
+ either of these is set to ``amd-sev-es`` along with the parameter/propery to
+ enable memory encryption, it would be internally translated to
+ ``resources:MEM_ENCRYPTION_CONTEXT_V2=1`` which would
+ be added to the flavor extra specs in the ``RequestSpec`` object.
+ if these new mechanism parameter/property is absent or set to ``amd-sev``
+ then it would be translated to ``resources:MEM_ENCRYPTION_CONTEXT=1``.
+
+Alternatives
+------------
+
+TBD
+
+Data model impact
+-----------------
+
+A new resource class will be used to inventory slots for SEV-ES guests on
+SEV-ES-capable compute hosts.
+
+A new configuration option will be used (at least in the short term)
+to specify the maximum number of SEV-ES guests runnable on each compute
+host. This overrides the maximum number determined using the number exposed by
+libvirt API, in case the given limit is lower than the actual limit.
+
+REST API impact
+---------------
+
+None
+
+Security impact
+---------------
+
+None
+
+Notifications impact
+--------------------
+
+None
+
+Other end user impact
+---------------------
+
+The end user will harness SEV-ES through the existing mechanisms of
+resources in flavor extra specs and image properties.
+
+Performance Impact
+------------------
+
+No performance impact on nova is anticipated.
+
+Perfomance impact for the other parts are same as the existing SEV support
+feature.
+
+Other deployer impact
+---------------------
+
+In order for users to be able to use SEV-ES, the operator will need to
+perform the following steps:
+
+- Deploy SEV-ES-capable hardware as nova compute hosts.
+
+- Set maximum ASID in BIOS (or UEFI) to a value greater than 0.
+
+- Ensure that they have an appropriately configured software stack, so
+ that the various layers are all SEV-ES ready:
+
+ - kernel >= 4.16
+ - QEMU >= 6.1.0
+ - libvirt >= 4.5
+ - ovmf >= commit 7f0b28415cb4 2020-08-12
+
+Finally, a cloud administrator will need to define SEV-ES-enabled flavors
+as described above, unless it is sufficient for users to define
+SEV-ES-enabled images.
+
+Developer impact
+----------------
+
+None
+
+Upgrade impact
+--------------
+
+None
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+ kajinamit (irc: tkajinam)
+
+Other contributors:
+ None
+
+Work Items
+----------
+
+Work items or tasks -- break the feature up into the things that need to be
+done to implement it. Those parts might end up being done by different people,
+but we're mostly trying to understand the timeline for implementation.
+
+Consider creating an ordering of patches, that allows gradually merging
+instead of the need to merge them all at once. For example if you are
+introducing a feature that requires implementation changes in multiple VM
+lifecycle operations then first add a step that rejects all the not yet
+supported actions with a HTTP 400 Bad Request. The error should explain that
+the is not supported with at this time. Then gradually
+remove the limitation as you progress with the implementation. This way we can
+merge your changes gradually and regardless when the feature freeze hit we can
+be sure that the system is consistent.
+
+Future work
+-----------
+
+None
+
+
+Dependencies
+============
+
+* Special hardware which supports SEV-ES for development, testing, and CI.
+
+* Recent versions of the hypervisor software stack which all support
+ SEV-ES, as detailed in `Other deployer impact`_ above.
+
+
+Testing
+=======
+
+TBD
+
+
+Documentation Impact
+====================
+
+TBD
+
+
+References
+==========
+
+TBD
+
+
+History
+=======
+
+
+.. list-table:: Revisions
+ :header-rows: 1
+
+ * - Release Name
+ - Description
+ * - 2024.2 Dalmetian
+ - Introduced