{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":108168384,"defaultBranch":"master","name":"qemu","ownerLogin":"AMDESE","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2017-10-24T18:40:02.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/30510261?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1720505800.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"8f42ec461a5ca7ccff4cdbe989c56f11a75ba7c5","ref":"refs/heads/buslock_threshold","pushedAt":"2024-07-09T06:16:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"Kullu14","name":"Manali Shukla","path":"/Kullu14","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11070117?s=80&v=4"},"commit":{"message":"i386/cpu: Add buslock threshold feature bit on EPYC-Turin CPU model\n\nAdd the support for the buslock threashold feature bit on AMD guests.\n\nSigned-off-by: Manali Shukla <manali.shukla@amd.com>","shortMessageHtmlLink":"i386/cpu: Add buslock threshold feature bit on EPYC-Turin CPU model"}},{"before":null,"after":"f1f530ba21335803cc7955142da84945a2b204cd","ref":"refs/heads/snp-guest-req-v1-wip1","pushedAt":"2024-06-21T13:26:57.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"i386/sev: Add KVM_EXIT_COCO handling for Extended Guest Requests\n\nThe GHCB specification[1] defines a VMGEXIT-based Guest Request\nhypercall to allow an SNP guest to issue encrypted requests directly to\nSNP firmware to do things like query the attestation report for the\nguest. These are generally handled purely in the kernel.\n\nIn some some cases, it's useful for the host to be able to additionally\nsupply the certificate chain for the signing key that SNP firmware uses\nto sign these attestation reports. To allow for, the GHCB specification\ndefines an Extended Guest Request where this certificate data can be\nprovided in a special format described in the GHCB spec. This\ncertificate data may be global or guest-specific depending on how the\nguest was configured. Rather than providing interfaces to manage these\nwithin the kernel, KVM handles this by forwarding the Extended Guest\nRequests on to userspace so the certificate data can be provided in the\nexpected format. It does this in the form of a KVM_EXIT_COCO event with\na sub-type of KVM_EXIT_COCO_REQ_CERTS.\n\nAdd a certs-path parameter to the sev-snp-guest object so that the\ncorresponding certificate data can be provided when\nKVM_EXIT_COCO_REQ_CERTS is issued.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>\nSigned-off-by: Pankaj Gupta <pankaj.gupta@amd.com>","shortMessageHtmlLink":"i386/sev: Add KVM_EXIT_COCO handling for Extended Guest Requests"}},{"before":"b9db9ed793ea6916a351e89b9de17b9c66bd65e3","after":"5e9eb3a549dfd47823044ed4e483d4f340a552a0","ref":"refs/heads/tio","pushedAt":"2024-06-04T12:32:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"aik","name":"Alexey Kardashevskiy","path":"/aik","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1146004?s=80&v=4"},"commit":{"message":"vfio/tio: Bind TDI to SNP VM\n\nRunning trusted IO requires binding a passed through PCI function\nto a VM. The PCIe's TDISP protocol describes the state machine\nwhich is implemented in the trusted agent (TSM). A part of setup is binding\na TDI (a descriptor of the TDISP state of a secure PCI function in\nthe physical adapted).\n\nAdd TDI_BIND call to VFIO device upon a request from the confidential VM.\nThe confidential VM makes such call from the device probing function so\nsuch driver can enable the device first, receive the TDI interface report\nand validate the device resources in the TSM.\n\nThis could potentially be done at the machine reset or on the device's\nenablement (MMIO or MASTER in the command register), however TDISP\nprohibits changes to MMIO and MASTER bits in the command register after\nthe binding step (TBD).\n\nx-pre-bind is removed from now as not supported.\n\nTested with a SRIOV VF as:\necho -e device_add vfio-pci,host=e1:04.0,bus=r0,id=v0,iommufd=i0 | nc -q 0  -U ./qemu.mon.q.tvm\n\nSigned-off-by: Alexey Kardashevskiy <aik@amd.com>","shortMessageHtmlLink":"vfio/tio: Bind TDI to SNP VM"}},{"before":"7d10539bd5b276fa2aff6998075588a40f0d3b8b","after":"b9db9ed793ea6916a351e89b9de17b9c66bd65e3","ref":"refs/heads/tio","pushedAt":"2024-05-28T13:16:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"aik","name":"Alexey Kardashevskiy","path":"/aik","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1146004?s=80&v=4"},"commit":{"message":"vfio/tio: Bind TDI to the machine\n\nRunning trusted IO requires binding a passed through PCI function\nto a VM. The PCIe's TDISP protocol describes the state machine\nwhich is implemented in the trusted agent (TSM). A part of setup is binding\na TDI (a descriptor of the TDISP state of a secure PCI function in\nthe physical adapted).\n\nAdd TDI_BIND call to VFIO device upon a request from the confidential VM.\nThe confidential VM makes such call from the device probing function so\nsuch driver can enable the device first, receive the TDI interface report\nand validate the device resources in the TSM.\n\nThis could potentially be done at the machine reset or on the device's\nenablement (MMIO or MASTER in the command register), however TDISP\nprohibits changes to MMIO and MASTER bits in the command register after\nthe binding step (TBD).\n\nTested with a SRIOV VF as:\necho -e device_add vfio-pci,host=e1:04.0,bus=r,0x-tio-pre=true,\\\nx-tio-pvt=true,id=v0,iommufd=i0 | nc -q 0  -U ./qemu.mon.q.tvm\n\nSigned-off-by: Alexey Kardashevskiy <aik@amd.com>","shortMessageHtmlLink":"vfio/tio: Bind TDI to the machine"}},{"before":"6913b311064973336af7b5d3164833ad76f221aa","after":"7d10539bd5b276fa2aff6998075588a40f0d3b8b","ref":"refs/heads/tio","pushedAt":"2024-05-20T13:53:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"aik","name":"Alexey Kardashevskiy","path":"/aik","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1146004?s=80&v=4"},"commit":{"message":"vfio/tio: Bind TDI to the machine\n\nRunning trusted IO requires binding a passed through PCI function\nto a VM. The PCIe's TDISP protocol describes the state machine\nwhich is implemented in the trusted agent (TSM). A part of setup is binding\na TDI (a descriptor of the TDISP state of a secure PCI function in\nthe physical adapted).\n\nAdd TDI_BIND call to VFIO device upon a request from the confidential VM.\nThe confidential VM makes such call from the device probing function so\nsuch driver can enable the device first, receive the TDI interface report\nand validate the device resources in the TSM.\n\nThis could potentially be done at the machine reset or on the device's\nenablement (MMIO or MASTER in the command register), however TDISP\nprohibits changes to MMIO and MASTER bits in the command register after\nthe binding step (TBD).\n\nTested with a SRIOV VF as:\necho -e device_add vfio-pci,host=e1:04.0,bus=r,0x-tio-pre=true,\\\nx-tio-pvt=true,id=v0,iommufd=i0 | nc -q 0  -U ./qemu.mon.q.tvm\n\nSigned-off-by: Alexey Kardashevskiy <aik@amd.com>","shortMessageHtmlLink":"vfio/tio: Bind TDI to the machine"}},{"before":null,"after":"6913b311064973336af7b5d3164833ad76f221aa","ref":"refs/heads/tio","pushedAt":"2024-05-20T13:53:46.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"aik","name":"Alexey Kardashevskiy","path":"/aik","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1146004?s=80&v=4"},"commit":{"message":"DBG (leftovers)","shortMessageHtmlLink":"DBG (leftovers)"}},{"before":"a4f571b72e036d7a2936e2a14bbb19e822b22c8d","after":"fb924a5139bff1d31520e007ef97b616af1e22a1","ref":"refs/heads/snp-latest","pushedAt":"2024-05-14T22:55:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"[SQUASH] Don't warn about treating unknown memory type as zero page\n\nIt will get printed much for every upstream OVMF going forward and so\nisn't really that helpful for diagnosing anything special. It would be\nmore interesting to print such messages when SVSM is enabled, in which\ncase shouldn't encounter any unknown memory types, which would then be\nworth warning about.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"[SQUASH] Don't warn about treating unknown memory type as zero page"}},{"before":null,"after":"3fcdc0c2207f45c0f48b1a2cd2c53e5f9016f698","ref":"refs/heads/passthrough-pmu-rfc-svm-vibs","pushedAt":"2024-05-02T14:38:13.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"Kullu14","name":"Manali Shukla","path":"/Kullu14","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11070117?s=80&v=4"},"commit":{"message":"i386: Add feature flag for VIBS and EXTLVT\n\nAdd \"vibs\" and \"extlvt\" feature flag to enable VIBS support.\n\nSigned-off-by: Manali Shukla <manali.shukla@amd.com>","shortMessageHtmlLink":"i386: Add feature flag for VIBS and EXTLVT"}},{"before":"62cb57b7930bc09941616ca40f6c33f96c0584ac","after":"fd119799b799e35e866cc0c4d790253bcae44561","ref":"refs/heads/snp-v4-wip3c","pushedAt":"2024-05-01T07:22:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*i386/sev: Add support for specifying ghcb-version\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*i386/sev: Add support for specifying ghcb-version"}},{"before":null,"after":"62cb57b7930bc09941616ca40f6c33f96c0584ac","ref":"refs/heads/snp-v4-wip3c","pushedAt":"2024-05-01T07:03:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*i386/sev: Add support for specifying ghcb-version\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*i386/sev: Add support for specifying ghcb-version"}},{"before":null,"after":"372ab77217b67bfe421ab25291df882d9a18d9ce","ref":"refs/heads/snp-v4-wip3b","pushedAt":"2024-04-21T16:37:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*squash: i386/sev: Add handling to encrypt/finalize guest launch data\n\nTODO: also change \"Co-authored-by: Michael Roth\" to \"Co-developed-by\"\n      while there.\n\nThis updates the KVM_SEV_SNP_LAUNCH_UPDATE call to handle partial update\nresponses.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*squash: i386/sev: Add handling to encrypt/finalize guest launch data"}},{"before":null,"after":"919cfafb8ab0625aed2a30cdfab245899636a9c8","ref":"refs/heads/snp-v4-wip3","pushedAt":"2024-04-18T18:48:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*linux-headers: Update headers for snp-host-v13-wip9\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*linux-headers: Update headers for snp-host-v13-wip9"}},{"before":"c139a28810964fe90804421561fb6fb0ab2c5056","after":"a4f571b72e036d7a2936e2a14bbb19e822b22c8d","ref":"refs/heads/snp-latest","pushedAt":"2024-04-16T10:54:09.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"[TEMP] Revert \"RAMBlock: make guest_memfd require uncoordinated discard\"\n\nThis reverts commit 4192ba5df7485b95d0c82d45e5ca5843319a176d.\n\nThis commit specifically disabled VFIO under the assumption that\nRamDiscardManager must be implemented, but the other alternative is to\nnot discard memory at all. That's the approach taken in the current\ntree, so revert this check to re-enable VFIO.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"[TEMP] Revert \"RAMBlock: make guest_memfd require uncoordinated discard\""}},{"before":"f246dd2ad51d2c6c3ce9a588a8ce9c6a2d8c20e1","after":"c139a28810964fe90804421561fb6fb0ab2c5056","ref":"refs/heads/snp-latest","pushedAt":"2024-04-10T18:47:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"[TEMP] kvm: Make kvm_convert_memory() obey ram_block_discard_is_enabled()\n\nTODO: switch to using RamDiscardManager implementation when available to\n      avoided doubled memory usage\n\nSome subsystems like VFIO might disable ram block discard for\nuncoordinated cases. Since kvm_convert_memory()/guest_memfd don't\nimplement a RamDiscardManager handler to convey discard operations to\nvarious listeners like VFIO. Because of this, sequences like the\nfollowing can result due to stale IOMMU mappings:\n\n  - convert page shared->private\n  - discard shared page\n  - convert page private->shared\n  - new page is allocated\n  - issue DMA operations against that shared page\n\nAddress this by taking ram_block_discard_is_enabled() into account when\ndeciding whether or not to discard pages.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"[TEMP] kvm: Make kvm_convert_memory() obey ram_block_discard_is_enabl…"}},{"before":null,"after":"bd5828321c2f16f99ffe2cd34600484172ef0c06","ref":"refs/heads/sev-init-legacy1","pushedAt":"2024-04-09T22:59:31.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"hw/i386/sev: Use legacy SEV VM types for older machine types\n\nNewer 9.1 machine types will default to using the KVM_SEV_INIT2 API for\ncreating SEV/SEV-ES going forward. However, this API results in guest\nmeasurement changes which are generally not expected for users of these\nolder guest types and can cause disruption if they switch to a newer\nQEMU/kernel version. Avoid this by continuing to use the older\nKVM_SEV_INIT/KVM_SEV_ES_INIT APIs for older machine types.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"hw/i386/sev: Use legacy SEV VM types for older machine types"}},{"before":null,"after":"0e5b131212a70a73f3b79d333d1fa5487cf721bf","ref":"refs/heads/wip/v4.2.0_amdiommu_x2avic_20240403_1","pushedAt":"2024-04-03T09:12:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ssuthiku-amd","name":"Suravee Suthikulpanit","path":"/ssuthiku-amd","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/102224985?s=80&v=4"},"commit":{"message":"qemu_init: increase NOFILE soft limit on POSIX\n\nIn many configurations, e.g. multiple vNICs with multiple queues or\nwith many Ceph OSDs, the default soft limit of 1024 is not enough.\nQEMU is supposed to work fine with file descriptors >= 1024 and does\nnot use select() on POSIX. Bump the soft limit to the allowed hard\nlimit to avoid issues with the aforementioned configurations.\n\nOf course the limit could be raised from the outside, but the man page\nof systemd.exec states about 'LimitNOFILE=':\n\n> Don't use.\n> [...]\n> Typically applications should increase their soft limit to the hard\n> limit on their own, if they are OK with working with file\n> descriptors above 1023,\n\nIf the soft limit is already the same as the hard limit, avoid the\nsuperfluous setrlimit call. This can avoid a warning with a strict\nseccomp filter blocking setrlimit if NOFILE was already raised before\nexecuting QEMU.\n\nBuglink: https://bugzilla.proxmox.com/show_bug.cgi?id=4507\nReviewed-by: Daniel P. Berrangé <berrange@redhat.com>\nSigned-off-by: Fiona Ebner <f.ebner@proxmox.com>\nSigned-off-by: Daniel P. Berrangé <berrange@redhat.com>\nOriginal-commit: 03e471c41d8b","shortMessageHtmlLink":"qemu_init: increase NOFILE soft limit on POSIX"}},{"before":null,"after":"01e134fbb5ffc5249762e7b5bc9283ee14da2f40","ref":"refs/heads/snp-v4-wip2","pushedAt":"2024-03-29T21:56:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"i386/ev: Add support for vlek-required flag\n\nThis flag can be used to force the use of VLEK endorsement keys for\nattestions rather than allowing the guest to choose between VCEK/VLEK.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"i386/ev: Add support for vlek-required flag"}},{"before":"9d222640293dd6ea8ea4c38bb2fe37dc6b06a778","after":"668a544072dcc58bad9bf6c1c4676e4ba38225c4","ref":"refs/heads/snp-v3-rfc","pushedAt":"2024-03-21T13:37:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"hw/i386: Add support for loading BIOS using guest_memfd\n\nTODO: - Add proper handling for non-64K-aligned BIOS images.\n      - Add proper handling for BIOS pflash area which should be\n        initially mapped as shared, resulting in unecessary\n        KVM_EXIT_MEMORY_FAULTs\n\nWhen guest_memfd is enabled, the BIOS is generally part of the initial\nencrypted guest image and will be accessed as private guest memory. Add\nthe necessary changes to set up the associated RAM region with a\nguest_memfd backend to allow for this.\n\nCurrent support centers around using -bios to load the BIOS data.\nSupport for loading the BIOS via pflash requires additional enablement\nsince those interfaces rely on the use of ROM memory regions which make\nuse of the KVM_MEM_READONLY memslot flag, which is not supported for\nguest_memfd-backed memslots.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"hw/i386: Add support for loading BIOS using guest_memfd"}},{"before":null,"after":"2ac5c3fe16cbf7c321b1003accd5df8e1e626c9f","ref":"refs/heads/passthrough-pmu-rfc-svm","pushedAt":"2024-03-20T14:51:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"sandip4n","name":"Sandipan Das","path":"/sandip4n","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/31861871?s=80&v=4"},"commit":{"message":"target/i386: Add missing feature bits in EPYC-Genoa model\n\nAdd the PerfMonV2 and LbrExtV2 feature bits to the EPYC-Genoa model and\nbump the version. The new feature bits will be available in EPYC-Genoa-v2.\n\nSigned-off-by: Sandipan Das <sandipan.das@amd.com>","shortMessageHtmlLink":"target/i386: Add missing feature bits in EPYC-Genoa model"}},{"before":null,"after":"9d222640293dd6ea8ea4c38bb2fe37dc6b06a778","ref":"refs/heads/snp-v3-rfc","pushedAt":"2024-03-20T08:29:33.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"hw/i386: Add support for loading BIOS using guest_memfd\n\nTODO: - Add proper handling for non-64K-aligned BIOS images.\n      - Add proper handling for BIOS pflash area which should be\n        initially mapped as shared, resulting in unecessary\n        KVM_EXIT_MEMORY_FAULTs\n\nWhen guest_memfd is enabled, the BIOS is generally part of the initial\nencrypted guest image and will be accessed as private guest memory. Add\nthe necessary changes to set up the associated RAM region with a\nguest_memfd backend to allow for this.\n\nCurrent support centers around using -bios to load the BIOS data.\nSupport for loading the BIOS via pflash requires additional enablement\nsince those interfaces rely on the use of ROM memory regions which make\nuse of the KVM_MEM_READONLY memslot flag, which is not supported for\nguest_memfd-backed memslots.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"hw/i386: Add support for loading BIOS using guest_memfd"}},{"before":"b6ee1218e6c9b98a556841615dd10d094e648393","after":"f246dd2ad51d2c6c3ce9a588a8ce9c6a2d8c20e1","ref":"refs/heads/snp-latest","pushedAt":"2024-02-21T22:54:35.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*target/i386: Drop reference to KVM_SEV_SNP_PAGE_TYPE_VMSA\n\nThis is no longer exposed to userspace.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*target/i386: Drop reference to KVM_SEV_SNP_PAGE_TYPE_VMSA"}},{"before":"0a5c66e610aca1ed3f69d457a3fa49fbe89066da","after":"36b182687b73a0b6aa5a2dcdd02c96e5f81d96d9","ref":"refs/heads/wip/amd-viommu_no-gcr3trp-no-gstbuftrp_20240207","pushedAt":"2024-02-08T13:34:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ssuthiku-amd","name":"Suravee Suthikulpanit","path":"/ssuthiku-amd","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/102224985?s=80&v=4"},"commit":{"message":"QEMU launch script","shortMessageHtmlLink":"QEMU launch script"}},{"before":null,"after":"0a5c66e610aca1ed3f69d457a3fa49fbe89066da","ref":"refs/heads/wip/amd-viommu_no-gcr3trp-no-gstbuftrp_20240207","pushedAt":"2024-02-08T13:32:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ssuthiku-amd","name":"Suravee Suthikulpanit","path":"/ssuthiku-amd","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/102224985?s=80&v=4"},"commit":{"message":"Adding Command Buffer Update handling","shortMessageHtmlLink":"Adding Command Buffer Update handling"}},{"before":null,"after":"aa945b3e495f812e3875670550c2f72815b0bc84","ref":"refs/heads/zhenzhong/wip/iommufd_nesting_rfcv1_amd_viommu+pasid+xt_20240129","pushedAt":"2024-01-29T12:12:33.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ssuthiku-amd","name":"Suravee Suthikulpanit","path":"/ssuthiku-amd","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/102224985?s=80&v=4"},"commit":{"message":"XT support","shortMessageHtmlLink":"XT support"}},{"before":null,"after":"5509743005ff5d989732fdda1fc1ef43be2f529f","ref":"refs/heads/svsm-preview-v4","pushedAt":"2024-01-26T22:40:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tlendacky","name":"Tom Lendacky","path":"/tlendacky","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26725967?s=80&v=4"},"commit":{"message":"target/i386/sev: Add support for an SVSM\n\nAdd a new machine property to provide SVSM support. The new svsm option\npoints to a file that contains the SVSM binary.\n\nThe SVSM binary is initialized before the system firmware. The SVSM binary\nlives in a memslot with a GPA outside of the guest memory limit, as\ndefined by the SVSM GPA and SVSM memory size found in the SVSM binary\nGUIDed table. After loading the SVSM, a LAUNCH_UPDATE is performed to\nencrypt and measure the SVSM at the VMPL0 level. The CPUID page and the\nSecrets page LAUNCH_UPDATE calls are applied to the SVSM binary locations.\n\nThe guest system firmware continues to be encrypted and measured, but with\nsome changes if an SVSM is being used:\n  - The system firmware is encrypted and measured at the VMPL1 level\n  - The BSP register state is no longer obtained from the system firmware\n    GUIDed table\n  - The CPUID page and Secrets page locations are now treated as type zero\n    pages during LAUNCH_UPDATE\n\nThe system firmware GPA is now provided in the Qemu firmware configuration\ninterface so that the SVSM can locate and parse the firmware information\nmore easily in order to locate the firmware GUIDed table information.\n\nWith the new BSP register state being supplied by the SVSM binary, the\nguest will begin execution in the SVSM instead of the system firmware.\n\nCo-developed-by: Carlos Bilbao <carlos.bilbao@amd.com>\nSigned-off-by: Carlos Bilbao <carlos.bilbao@amd.com>\nSigned-off-by: Tom Lendacky <thomas.lendacky@amd.com>","shortMessageHtmlLink":"target/i386/sev: Add support for an SVSM"}},{"before":"fe4c9e8e7e7ddac4b19c4366c1f105ffc4a78482","after":"b6ee1218e6c9b98a556841615dd10d094e648393","ref":"refs/heads/snp-latest","pushedAt":"2024-01-13T22:25:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*skip RAMBlock notifiers for SNP\n\nSEV uses these to pin pages, SNP doesn't need this since it relies on\ngmem for any private pages.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*skip RAMBlock notifiers for SNP"}},{"before":"798d394eca36921a4fcf99cffc321cf72260a711","after":"b6ee1218e6c9b98a556841615dd10d094e648393","ref":"refs/heads/snp-v3-wip","pushedAt":"2024-01-11T00:23:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*skip RAMBlock notifiers for SNP\n\nSEV uses these to pin pages, SNP doesn't need this since it relies on\ngmem for any private pages.\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*skip RAMBlock notifiers for SNP"}},{"before":"c36ffa5fc218744030380ce32f442b1fcda97b13","after":"798d394eca36921a4fcf99cffc321cf72260a711","ref":"refs/heads/snp-v3-wip","pushedAt":"2024-01-10T00:39:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*fix non-SNP handling for memory regions\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*fix non-SNP handling for memory regions"}},{"before":null,"after":"c36ffa5fc218744030380ce32f442b1fcda97b13","ref":"refs/heads/snp-v3-wip","pushedAt":"2023-12-30T16:45:34.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*initial support for supplying certs for extended requests\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*initial support for supplying certs for extended requests"}},{"before":"bbc1bfb6bfb3cde4c22755cedd5b71e651ca35e8","after":"fe4c9e8e7e7ddac4b19c4366c1f105ffc4a78482","ref":"refs/heads/snp-latest","pushedAt":"2023-11-10T20:55:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mdroth","name":"Michael Roth","path":"/mdroth","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/733328?s=80&v=4"},"commit":{"message":"*sev: combine contiguous memory attr updates\n\nSigned-off-by: Michael Roth <michael.roth@amd.com>","shortMessageHtmlLink":"*sev: combine contiguous memory attr updates"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEek3R3wA","startCursor":null,"endCursor":null}},"title":"Activity · AMDESE/qemu"}