diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/pcie_sriov.txt | 5 | ||||
| -rw-r--r-- | docs/specs/acpi_hest_ghes.rst | 28 | ||||
| -rw-r--r-- | docs/system/devices/vhost-user.rst | 20 |
3 files changed, 26 insertions, 27 deletions
diff --git a/docs/pcie_sriov.txt b/docs/pcie_sriov.txt index ab2142807f..00d7bd93fd 100644 --- a/docs/pcie_sriov.txt +++ b/docs/pcie_sriov.txt @@ -72,8 +72,7 @@ setting up a BAR for a VF. 2) Similarly in the implementation of the virtual function, you need to make it a PCI Express device and add a similar set of capabilities except for the SR/IOV capability. Then you need to set up the VF BARs as - subregions of the PFs SR/IOV VF BARs by calling - pcie_sriov_vf_register_bar() instead of the normal pci_register_bar() call: + subregions of the PFs SR/IOV VF BARs by calling pci_register_bar(): pci_your_vf_dev_realize( ... ) { @@ -83,7 +82,7 @@ setting up a BAR for a VF. pcie_ari_init(d, 0x100); ... memory_region_init(mr, ... ) - pcie_sriov_vf_register_bar(d, bar_nr, mr); + pci_register_bar(d, bar_nr, bar_type, mr); ... } diff --git a/docs/specs/acpi_hest_ghes.rst b/docs/specs/acpi_hest_ghes.rst index c3e9f8d9a7..aaf7b1ad11 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/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst index 35259d8ec7..bddf8df5ed 100644 --- a/docs/system/devices/vhost-user.rst +++ b/docs/system/devices/vhost-user.rst @@ -62,26 +62,20 @@ platform details for what sort of virtio bus to use. The referenced *daemons* are not exhaustive, any conforming backend implementing the device and using the vhost-user protocol should work. -vhost-user-device -^^^^^^^^^^^^^^^^^ +vhost-user-test-device +^^^^^^^^^^^^^^^^^^^^^^ -The vhost-user-device is a generic development device intended for -expert use while developing new backends. The user needs to specify -all the required parameters including: +The vhost-user-test-device is a generic development device intended +for expert use while developing new backends. The user needs to +specify all the required parameters including: - Device ``virtio-id`` - The ``num_vqs`` it needs and their ``vq_size`` - The ``config_size`` if needed .. note:: - To prevent user confusion you cannot currently instantiate - vhost-user-device without first patching out:: - - /* Reason: stop inexperienced users confusing themselves */ - dc->user_creatable = false; - - in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and - rebuilding. + While this is a useful device for development it is not recommended + for production use. vhost-user daemon ================= |