Re: [Qemu-devel] [PATCH v18 5/7] pvpanic: add document of pvpanic

[Markus Armbruster]

Hu Tao <address@hidden> writes:

> Signed-off-by: Hu Tao <address@hidden>
> ---
>  docs/specs/pvpanic.txt | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 docs/specs/pvpanic.txt
>
> diff --git a/docs/specs/pvpanic.txt b/docs/specs/pvpanic.txt
> new file mode 100644
> index 0000000..d72d667
> --- /dev/null
> +++ b/docs/specs/pvpanic.txt
> @@ -0,0 +1,37 @@
> +PVPANIC DEVICE
> +==============
> +
> +pvpanic device is a simulated ISA 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.
> +
> +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.
> +
> +ISA Interface
> +-------------
> +
> +pvpanic uses port 0x505 to receive a panic event from the guest. On
> +write, bit 0 is set to indicate guest panic has happened. On read, bit
> +0 is set to indicate guest panic notification is supported. Remaining
> +bits are reserved, and should be written as 0, and ignored on read.
> +
> +ACPI Interface
> +--------------
> +
> +pvpanic device is defined with ACPI ID "QEMU0001". Custom methods:
> +
> +RDPT:       To determine whether guest panic notification is supported.
> +Arguments:  None
> +Return:     Returns a byte, bit 0 set to indicate guest panic
> +            notification is supported. Other bits are reserved and
> +            should be ignored.
> +
> +WRPT:       To send a guest panic event
> +Arguments:  Arg0 is a byte, with bit 0 set to indicate guest panic has
> +            happened. Other bits are reserved and should be cleared.
> +Return:     None
> +
> +The ACPI device will automatically refer to the right port in case it
> +is modified.

Here, you implicitly state that the port is configurable.  Section "ISA
Interface" sounds like it was fixed to 0x505.  It's actually
configurable.  Rephrase it a bit there?  See my reply to 3/7 for a
possible wording.