Update patch set 13

Patch Set 13: Code-Review-1

(4 comments)

Patch-set: 13
Reviewer: Gerrit User 6962 <6962@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Label: Code-Review=-1, da044b790b6591197fe9f528f6b3c248c62f85c9
This commit is contained in:
Gerrit User 6962 2024-04-10 12:48:03 +00:00 committed by Gerrit Code Review
parent 1d9aa8c4f0
commit 367fa2824f
1 changed files with 84 additions and 0 deletions

View File

@ -0,0 +1,84 @@
{
"comments": [
{
"unresolved": false,
"key": {
"uuid": "a09447d5_b675545c",
"filename": "/PATCHSET_LEVEL",
"patchSetId": 13
},
"lineNbr": 0,
"author": {
"id": 6962
},
"writtenOn": "2024-04-10T12:48:03Z",
"side": 1,
"message": "Hi! Thanks for taking this on. :-) I support the idea itself! This is a \"soft -1\" to discuss some initial comments inline.",
"revId": "7c4933d86f23cb3964513293e4e5e772f9875a97",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "2c29a6ca_64a4fd1c",
"filename": "specs/2024.2/approved/amd-sev-es-libvirt-support.rst",
"patchSetId": 13
},
"lineNbr": 27,
"author": {
"id": 6962
},
"writtenOn": "2024-04-10T12:48:03Z",
"side": 1,
"message": "We should also mention the important limitation of plain SEV that SEV-ES solves:\n\n- With plain SEV, the maximum number of encryption keys possible are 16. Each VM consumes a key to protect its memory. So you can run only 16 guests with encrypted memory.\n\n- With SEV-ES, this limit is increased to 500. So, with SEV-ES, you can run about 500 \"encrypted\" guests (with protected memory and CPU register state).",
"range": {
"startLine": 21,
"startChar": 1,
"endLine": 27,
"endChar": 19
},
"revId": "7c4933d86f23cb3964513293e4e5e772f9875a97",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "5fadd814_5e5680cc",
"filename": "specs/2024.2/approved/amd-sev-es-libvirt-support.rst",
"patchSetId": 13
},
"lineNbr": 34,
"author": {
"id": 6962
},
"writtenOn": "2024-04-10T12:48:03Z",
"side": 1,
"message": "Thanks for mentioning the \"keep the proposal as much compatible\" with SEV-SNP as possible. \n\nI know SEV-SNP is still a work in progress in lower layers, and is more complex than ES — just the QEMU RFC itself seems to be quite complicated. Here\u0027s[1] the latest in-progress v3 of SEV-SNP support on qemu-devel.\n\n\n[1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg04978.html\n-- [PATCH RFC v3 00/49] Add AMD Secure Nested Paging (SEV-SNP) support",
"range": {
"startLine": 30,
"startChar": 0,
"endLine": 34,
"endChar": 70
},
"revId": "7c4933d86f23cb3964513293e4e5e772f9875a97",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "66c58da5_c2719fc4",
"filename": "specs/2024.2/approved/amd-sev-es-libvirt-support.rst",
"patchSetId": 13
},
"lineNbr": 57,
"author": {
"id": 6962
},
"writtenOn": "2024-04-10T12:48:03Z",
"side": 1,
"message": "Also consider the below two things:\n\n- `virt-qemu-sev-validate` tool[2] — it lets you \"validate\" the measurement of a SEV-ES guest, among other features. Even if we don\u0027t use this, we should at least mention this in the documentation.\n\n- Boot attestation — users who know why they want to use SEV-ES usually also know that \"guest boot attestation\" important before they can trust that the guest is truly confidential. Again, we don\u0027t have to do it as part of this change, but at least we should point to upstream libvirt docs[3] to give enough guidance.\n\n It also talks about the requirements, such as the expected configuration of the \"\u003claunchSecurity\u003e\" XML element, (already part of Nova\u0027s XML modelling code).\n \n[2] https://libvirt.org/manpages/virt-qemu-sev-validate.html\n\n[3] https://libvirt.org/kbase/launch_security_sev.html#guest-attestation-for-sev-sev-es-from-a-trusted-host",
"revId": "7c4933d86f23cb3964513293e4e5e772f9875a97",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
}
]
}