diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/clocks.rst | 16 | ||||
| -rw-r--r-- | docs/specs/pci-ids.txt | 1 | ||||
| -rw-r--r-- | docs/specs/pvpanic.txt | 13 | ||||
| -rw-r--r-- | docs/system/arm/virt.rst | 2 |
4 files changed, 31 insertions, 1 deletions
diff --git a/docs/devel/clocks.rst b/docs/devel/clocks.rst index 2548d84232..c54bbb8240 100644 --- a/docs/devel/clocks.rst +++ b/docs/devel/clocks.rst @@ -235,6 +235,22 @@ object during device instance init. For example: /* set initial value to 10ns / 100MHz */ clock_set_ns(clk, 10); +To enforce that the clock is wired up by the board code, you can +call ``clock_has_source()`` in your device's realize method: + +.. code-block:: c + + if (!clock_has_source(s->clk)) { + error_setg(errp, "MyDevice: clk input must be connected"); + return; + } + +Note that this only checks that the clock has been wired up; it is +still possible that the output clock connected to it is disabled +or has not yet been configured, in which case the period will be +zero. You should use the clock callback to find out when the clock +period changes. + Fetching clock frequency/period ------------------------------- diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt index abbdbca6be..5e407a6f32 100644 --- a/docs/specs/pci-ids.txt +++ b/docs/specs/pci-ids.txt @@ -64,6 +64,7 @@ PCI devices (other than virtio): 1b36:000d PCI xhci usb host adapter 1b36:000f mdpy (mdev sample device), linux/samples/vfio-mdev/mdpy.c 1b36:0010 PCIe NVMe device (-device nvme) +1b36:0011 PCI PVPanic device (-device pvpanic-pci) All these devices are documented in docs/specs. diff --git a/docs/specs/pvpanic.txt b/docs/specs/pvpanic.txt index a90fbca72b..8afcde11cc 100644 --- a/docs/specs/pvpanic.txt +++ b/docs/specs/pvpanic.txt @@ -1,7 +1,7 @@ PVPANIC DEVICE ============== -pvpanic device is a simulated ISA device, through which a guest panic +pvpanic device is a simulated device, through which a guest panic event is sent to qemu, and a QMP event is generated. This allows management apps (e.g. libvirt) to be notified and respond to the event. @@ -9,6 +9,9 @@ The management app has the option of waiting for GUEST_PANICKED events, and/or polling for guest-panicked RunState, to learn when the pvpanic device has fired a panic event. +The pvpanic device can be implemented as an ISA device (using IOPORT) or as a +PCI device. + ISA Interface ------------- @@ -24,6 +27,14 @@ bit 1: a guest panic has happened and will be handled by the guest; the host should record it or report it, but should not affect the execution of the guest. +PCI Interface +------------- + +The PCI interface is similar to the ISA interface except that it uses an MMIO +address space provided by its BAR0, 1 byte long. Any machine with a PCI bus +can enable a pvpanic device by adding '-device pvpanic-pci' to the command +line. + ACPI Interface -------------- diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst index 32dc5eb22e..27652adfae 100644 --- a/docs/system/arm/virt.rst +++ b/docs/system/arm/virt.rst @@ -43,6 +43,8 @@ The virt board supports: - Secure-World-only devices if the CPU has TrustZone: - A second PL011 UART + - A second PL061 GPIO controller, with GPIO lines for triggering + a system reset or system poweroff - A secure flash memory - 16MB of secure RAM |