commit 7069619ef727acc93c81f72ef390c465e63b3b70
author Sreenad Menon <quic_sreemeno@quicinc.com> Tue Sep 27 21:39:58 2022 +0530
committer Steven Moreland <smoreland@google.com> Wed Mar 15 18:22:44 2023 +0000
tree 3daa3f9d47adcf0b77259012b8cf4acc5efc7d96
parent f319faf8a070e5e5a7744ad0f64206d3a2704811

devices: virtio: Always inject interrupts if hypervisor can handle

Gunyah hypervisor supports virtio-mmio transport only in some
products on which CrosVM is also used. Qualcomm has developed
a wrapper program which uses CrosVM's libdevices crate.

Gunyah hypervisor has some optimizations for how virtio-mmio
register access are handled. Normally they are synchronous access -
meaning any access of virtio-mmio register by a guest will cause
a fault, which requires blocking the guest VCPU until the access
can be served by CrosVM running in a different VM. Since that could
induce long delays for guest (esp since the OS in which CrosVM is
hosted is considered untrusted), Gunyah hypervisor caches all
virtio-mmio registers in its address space.
Any read access is handled without requiring intervention from CrosVM.
Write access is handled asynchronously - i,e a write will cause
hypervisor to updates its copy of the register, unblock the guest vcpu
and simultaneously notify CrosVM about the update.
By the time CrosVM gets to notice the update, guest could have
progressed lot more.

This works reasonably well for many devices and registers.
One problem case is writes to VIRTIO_MMIO_INTERRUPT_ACK, which signals
the guest having seen an interrupt. CrosVM seems to rely on synchronous
handling of this register write. Any attempts to kick guest via signal
method of 'struct Interrupt' (devices/src/virtio/interrupt.rs) skips
sending a kick if prior kick is "not yet" acknowledged, which fails
if writes to VIRTIO_MMIO_INTERRUPT_ACK is asynchronous.

This patch introduces a 'async_intr_status' flag in signal method which allows
the kick to be always delivered to guest independent of the status of
acknowledgement of prior kicks. Hypervisor will queue kick requests and
deliver another kick after current kick is processed.

Its expected that only the Qualcomm wrapper program will initialize the
interrupt object with 'async_intr_status' flag set and hence the upstream
CrosVM should not be affected because of this change.

BUG=b:243368499

Change-Id: I76568d9d8bc3be00c75c52d4a51d39410c5c35b3