mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
b659ef9d35
qemu/target/i386/trace-events

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

17 lines
1.1 KiB
Plaintext
Raw Normal View History

docs: fix references to docs/devel/tracing.rst Commit e50caf4a5c ("tracing: convert documentation to rST") converted docs/devel/tracing.txt to docs/devel/tracing.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tracing.txt/tracing.rst/ $(git grep -l docs/devel/tracing.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-2-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-17 18:16:58 +03:00
# See docs/devel/tracing.rst for syntax documentation.
intel_iommu: add support for split irqchip In split irqchip mode, IOAPIC is working in user space, only update kernel irq routes when entry changed. When IR is enabled, we directly update the kernel with translated messages. It works just like a kernel cache for the remapping entries. Since KVM irqfd is using kernel gsi routes to deliver interrupts, as long as we can support split irqchip, we will support irqfd as well. Also, since kernel gsi routes will cache translated interrupts, irqfd delivery will not suffer from any performance impact due to IR. And, since we supported irqfd, vhost devices will be able to work seamlessly with IR now. Logically this should contain both vhost-net and vhost-user case. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [move trace-events lines into target-i386/trace-events] Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-14 08:56:25 +03:00
trace-events: Shorten file names in comments We spell out sub/dir/ in sub/dir/trace-events' comments pointing to source files. That's because when trace-events got split up, the comments were moved verbatim. Delete the sub/dir/ part from these comments. Gets rid of several misspellings. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190314180929.27722-3-armbru@redhat.com Message-Id: <20190314180929.27722-3-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-14 21:09:26 +03:00
# sev.c
sev/i386: add command to initialize the memory encryption context When memory encryption is enabled, KVM_SEV_INIT command is used to initialize the platform. The command loads the SEV related persistent data from non-volatile storage and initializes the platform context. This command should be first issued before invoking any other guest commands provided by the SEV firmware. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-08 15:48:44 +03:00
kvm_sev_init(void) ""
target/i386: tracing: format length values as hex Three trace events had a literal "0x" prefix but the 'len' values were formatted in decimal base. Keep the prefix and format the numbers as hex, as is usually the case for length of memory regions. Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20201103100745.160409-1-dovmurik@linux.vnet.ibm.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-11-03 13:07:45 +03:00
kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%zx"
kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%zx"
sev/i386: add command to create launch memory encryption context The KVM_SEV_LAUNCH_START command creates a new VM encryption key (VEK). The encryption key created with the command will be used for encrypting the bootstrap images (such as guest bios). Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-08 15:48:48 +03:00
kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
target/i386/sev: Use size_t for object sizes This code was using both uint32_t and uint64_t for len. Consistently use size_t instead. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/20240626194950.1725800-3-richard.henderson@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-06-26 22:49:49 +03:00
kvm_sev_launch_update_data(void *addr, size_t len) "addr %p len 0x%zx"
sev/i386: add support to LAUNCH_MEASURE command During machine creation we encrypted the guest bios image, the LAUNCH_MEASURE command can be used to retrieve the measurement of the encrypted memory region. This measurement is a signature of the memory contents that can be sent to the guest owner as an attestation that the memory was encrypted correctly by the firmware. VM management tools like libvirt can query the measurement using query-sev-launch-measure QMP command. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-08 15:48:51 +03:00
kvm_sev_launch_measurement(const char *value) "data %s"
sev/i386: finalize the SEV guest launch flow SEV launch flow requires us to issue LAUNCH_FINISH command before guest is ready to run. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-08 15:48:52 +03:00
kvm_sev_launch_finish(void) ""
sev: add sev-inject-launch-secret AMD SEV allows a guest owner to inject a secret blob into the memory of a virtual machine. The secret is encrypted with the SEV Transport Encryption Key and integrity is guaranteed with the Transport Integrity Key. Although QEMU facilitates the injection of the launch secret, it cannot access the secret. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20201027170303.47550-1-tobin@linux.ibm.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-10-27 20:03:03 +03:00
kvm_sev_launch_secret(uint64_t hpa, uint64_t hva, uint64_t secret, int len) "hpa 0x%" PRIx64 " hva 0x%" PRIx64 " data 0x%" PRIx64 " len %d"
target/i386/sev: add support to query the attestation report The SEV FW >= 0.23 added a new command that can be used to query the attestation report containing the SHA-256 digest of the guest memory and VMSA encrypted with the LAUNCH_UPDATE and sign it with the PEK. Note, we already have a command (LAUNCH_MEASURE) that can be used to query the SHA-256 digest of the guest memory encrypted through the LAUNCH_UPDATE. The main difference between previous and this command is that the report is signed with the PEK and unlike the LAUNCH_MEASURE command the ATTESATION_REPORT command can be called while the guest is running. Add a QMP interface "query-sev-attestation-report" that can be used to get the report encoded in base64. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Cc: Eric Blake <eblake@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Reviewed-by: James Bottomley <jejb@linux.ibm.com> Tested-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Connor Kuehl <ckuehl@redhat.com> Message-Id: <20210429170728.24322-1-brijesh.singh@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-04-29 20:07:28 +03:00
kvm_sev_attestation_report(const char *mnonce, const char *data) "mnonce %s data %s"
i386/sev: Add the SNP launch start context The SNP_LAUNCH_START is called first to create a cryptographic launch context within the firmware. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com> Message-ID: <20240530111643.1091816-16-pankaj.gupta@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:27 +03:00
kvm_sev_snp_launch_start(uint64_t policy, char *gosvw) "policy 0x%" PRIx64 " gosvw %s"
i386/sev: Add handling to encrypt/finalize guest launch data Process any queued up launch data and encrypt/measure it into the SNP guest instance prior to initial guest launch. This also updates the KVM_SEV_SNP_LAUNCH_UPDATE call to handle partial update responses. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com> Message-ID: <20240530111643.1091816-17-pankaj.gupta@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:28 +03:00
kvm_sev_snp_launch_update(uint64_t src, uint64_t gpa, uint64_t len, const char *type) "src 0x%" PRIx64 " gpa 0x%" PRIx64 " len 0x%" PRIx64 " (%s page)"
kvm_sev_snp_launch_finish(char *id_block, char *id_auth, char *host_data) "id_block %s id_auth %s host_data %s"
Reference in New Issue Copy Permalink