When a ring is created, the driver may require that the renderer reports it's status at least as often as the driver's configured
The renderer is permitted to report more often, but must not report less often and miss the reporting window. This allows renderer implementations for multiple rings to be lightweight, since the renderer can have a single reporting thread that just wakes at the fastest required rate configured by the driver and sets all monitored ring status bits at once. If it becomes more efficient to monitor each ring with separate threads (i.e. multiple rings with very different reporting rates), the protocol can still support this implementation detail without affecting the driver.
The driver then checks the shared status field for the new
VK_RING_STATUS_ALIVE_BIT_MESA. If set, the renderer is still alive and reported the status within the previous reporting window; all is well and the driver unsets the flag in preparation for the next reporting window. If unset, the renderer must have crashed and the driver
abort()s the guest app. Currently, the driver checks the status during
vn_relax() iterations that trigger "warn" messages and existing
FATAL status checks. Then we hardcode the reporting period to be shorter than the first such "warn" iteration in any
vn_relax(), with an added 1/4 second margin to avoid false positives. This can be made more flexible in the future, as needed.