diff options
Diffstat (limited to 'docs/specs')
| -rw-r--r-- | docs/specs/acpi_hest_ghes.rst | 28 | ||||
| -rw-r--r-- | docs/specs/ppc-xive.rst | 2 | ||||
| -rw-r--r-- | docs/specs/riscv-iommu.rst | 35 | ||||
| -rw-r--r-- | docs/specs/spdm.rst | 2 |
4 files changed, 32 insertions, 35 deletions
diff --git a/docs/specs/acpi_hest_ghes.rst b/docs/specs/acpi_hest_ghes.rst index c3e9f8d..aaf7b1a 100644 --- a/docs/specs/acpi_hest_ghes.rst +++ b/docs/specs/acpi_hest_ghes.rst @@ -89,12 +89,21 @@ Design Details addresses in the "error_block_address" fields with a pointer to the respective "Error Status Data Block" in the "etc/hardware_errors" blob. -(8) QEMU defines a third and write-only fw_cfg blob which is called - "etc/hardware_errors_addr". Through that blob, the firmware can send back - the guest-side allocation addresses to QEMU. The "etc/hardware_errors_addr" - blob contains a 8-byte entry. QEMU generates a single WRITE_POINTER command - for the firmware. The firmware will write back the start address of - "etc/hardware_errors" blob to the fw_cfg file "etc/hardware_errors_addr". +(8) QEMU defines a third and write-only fw_cfg blob to store the location + where the error block offsets, read ack registers and CPER records are + stored. + + Up to QEMU 9.2, the location was at "etc/hardware_errors_addr", and + contains a GPA for the beginning of "etc/hardware_errors". + + Newer versions place the location at "etc/acpi_table_hest_addr", + pointing to the GPA of the HEST table. + + Using above mentioned 'fw_cfg' files, the firmware can send back the + guest-side allocation addresses to QEMU. They contain a 8-byte entry. + QEMU generates a single WRITE_POINTER command for the firmware. The + firmware will write back the start address of either "etc/hardware_errors" + or HEST table at the corresponding fw_cfg file. (9) When QEMU gets a SIGBUS from the kernel, QEMU writes CPER into corresponding "Error Status Data Block", guest memory, and then injects platform specific @@ -105,8 +114,5 @@ Design Details kernel, on receiving notification, guest APEI driver could read the CPER error and take appropriate action. -(11) kvm_arch_on_sigbus_vcpu() uses source_id as index in "etc/hardware_errors" to - find out "Error Status Data Block" entry corresponding to error source. So supported - source_id values should be assigned here and not be changed afterwards to make sure - that guest will write error into expected "Error Status Data Block" even if guest was - migrated to a newer QEMU. +(11) kvm_arch_on_sigbus_vcpu() reports RAS errors via a SEA notifications, + when a SIGBUS event is triggered. diff --git a/docs/specs/ppc-xive.rst b/docs/specs/ppc-xive.rst index 83d43f6..968cc76 100644 --- a/docs/specs/ppc-xive.rst +++ b/docs/specs/ppc-xive.rst @@ -157,7 +157,7 @@ Interrupt flow from an O/S perspective After an event data has been enqueued in the O/S Event Queue, the IVPE raises the bit corresponding to the priority of the pending interrupt -in the register IBP (Interrupt Pending Buffer) to indicate that an +in the register IPB (Interrupt Pending Buffer) to indicate that an event is pending in one of the 8 priority queues. The Pending Interrupt Priority Register (PIPR) is also updated using the IPB. This register represent the priority of the most favored pending diff --git a/docs/specs/riscv-iommu.rst b/docs/specs/riscv-iommu.rst index 991d376..571a6a6 100644 --- a/docs/specs/riscv-iommu.rst +++ b/docs/specs/riscv-iommu.rst @@ -30,15 +30,15 @@ This will add a RISC-V IOMMU PCI device in the board following any additional PCI parameters (like PCI bus address). The behavior of the RISC-V IOMMU is defined by the spec but its operation is OS dependent. -As of this writing the existing Linux kernel support `linux-v8`_, not yet merged, -does not have support for features like VFIO passthrough. The IOMMU emulation -was tested using a public Ventana Micro Systems kernel repository in -`ventana-linux`_. This kernel is based on `linux-v8`_ with additional patches that -enable features like KVM VFIO passthrough with irqbypass. Until the kernel support -is feature complete feel free to use the kernel available in the Ventana Micro Systems -mirror. - -The current Linux kernel support will use the IOMMU device to create IOMMU groups +Linux kernel iommu support was merged in v6.13. QEMU IOMMU emulation can be +used with mainline kernels for simple IOMMU PCIe support. + +As of v6.17, it does not have support for features like VFIO passthrough. +There is a `VFIO`_ RFC series that is not yet merged. The public Ventana Micro +Systems kernel repository in `ventana-linux`_ can be used for testing the VFIO +functions. + +The v6.13+ Linux kernel support uses the IOMMU device to create IOMMU groups with any eligible cards available in the system, regardless of factors such as the order in which the devices are added in the command line. @@ -49,7 +49,7 @@ IOMMU kernel driver behaves: $ qemu-system-riscv64 \ -M virt,aia=aplic-imsic,aia-guests=5 \ - -device riscv-iommu-pci,addr=1.0,vendor-id=0x1efd,device-id=0xedf1 \ + -device riscv-iommu-pci,addr=1.0 \ -device e1000e,netdev=net1 -netdev user,id=net1,net=192.168.0.0/24 \ -device e1000e,netdev=net2 -netdev user,id=net2,net=192.168.200.0/24 \ (...) @@ -58,21 +58,11 @@ IOMMU kernel driver behaves: -M virt,aia=aplic-imsic,aia-guests=5 \ -device e1000e,netdev=net1 -netdev user,id=net1,net=192.168.0.0/24 \ -device e1000e,netdev=net2 -netdev user,id=net2,net=192.168.200.0/24 \ - -device riscv-iommu-pci,addr=1.0,vendor-id=0x1efd,device-id=0xedf1 \ + -device riscv-iommu-pci,addr=3.0 \ (...) Both will create iommu groups for the two e1000e cards. -Another thing to notice on `linux-v8`_ and `ventana-linux`_ is that the kernel driver -considers an IOMMU identified as a Rivos device, i.e. it uses Rivos vendor ID. To -use the riscv-iommu-pci device with the existing kernel support we need to emulate -a Rivos PCI IOMMU by setting 'vendor-id' and 'device-id': - -.. code-block:: bash - - $ qemu-system-riscv64 -M virt \ - -device riscv-iommu-pci,vendor-id=0x1efd,device-id=0xedf1 (...) - Several options are available to control the capabilities of the device, namely: - "bus": the bus that the IOMMU device uses @@ -84,6 +74,7 @@ Several options are available to control the capabilities of the device, namely: - "g-stage": enable g-stage support - "hpm-counters": number of hardware performance counters available. Maximum value is 31. Default value is 31. Use 0 (zero) to disable HPM support +- "vendor-id"/"device-id": pci device ID. Defaults to 1b36:0014 (Redhat) riscv-iommu-sys device ---------------------- @@ -111,6 +102,6 @@ riscv-iommu options: .. _iommu1.0.0: https://github.com/riscv-non-isa/riscv-iommu/releases/download/v1.0.0/riscv-iommu.pdf -.. _linux-v8: https://lore.kernel.org/linux-riscv/cover.1718388908.git.tjeznach@rivosinc.com/ +.. _VFIO: https://lore.kernel.org/linux-riscv/20241114161845.502027-17-ajones@ventanamicro.com/ .. _ventana-linux: https://github.com/ventanamicro/linux/tree/dev-upstream diff --git a/docs/specs/spdm.rst b/docs/specs/spdm.rst index f7de080..0e3ad25 100644 --- a/docs/specs/spdm.rst +++ b/docs/specs/spdm.rst @@ -102,7 +102,7 @@ Then you can add this to your QEMU command line: At which point QEMU will try to connect to the SPDM server. -Note that if using x64-64 you will want to use the q35 machine instead +Note that if using x86_64 you will want to use the q35 machine instead of the default. So the entire QEMU command might look like this .. code-block:: shell |