soft_apic: Add some diagnostics (#4079)

We've had a few test flakes of
openvmm_openhcl_uefi_x64_windows_datacenter_core_2022_x64_uefi_force_dma_bounce
recently. Copilot says these diagnostics are necessary to be able to
determine the root cause of the problem.

(cherry picked from commit 322aed5)

Author: smalis-msft

vm/devices/pci/pci_core/src/capabilities/msix.rs

@@ -140,7 +140,9 @@ struct MsiInterruptInner {
     route: Option<MsiRoute>,
     pending: bool,
     enabled: bool,
+    #[inspect(hex)]
     address: u64,
+    #[inspect(hex)]
     data: u32,
 }
 
@@ -269,7 +271,10 @@ impl InspectMut for MsixMessageTableEntry {
             .hex("data", self.state.data)
             .hex("control", self.state.control)
             .field("enabled", self.state.control & 1 == 0)
-            .field("is_pending", self.check_is_pending(true));
+            .field("is_pending", self.check_is_pending(true))
+            // Delivery state, which can diverge from the table above (e.g. an
+            // interrupt latched while masked).
+            .field("msi", &self.msi);
     }
 }
 

vmm_core/virt/src/x86/apic_software_device.rs

@@ -267,6 +267,14 @@ impl SignalMsi for ApicSoftwareDevice {
         if let Some(interrupt) = table.entries.get(index) {
             let target = interrupt.msi_params();
             self.target.signal_msi(None, target.address, target.data)
+        } else {
+            // A dropped MSI might leave the guest waiting forever for a device
+            // notification, so make it visible.
+            tracelimit::warn_ratelimited!(
+                address,
+                index,
+                "dropping MSI for unregistered interrupt"
+            );
         }
     }
 }