Project

General

Profile

Bug #12936

bhyve vlapic needs ability to bypass isrvec_stk

Added by Patrick Mooney about 1 month ago. Updated 14 days ago.

Status:
New
Priority:
Normal
Category:
bhyve
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
bhyve
Gerrit CR:

Description

The emulated APIC in bhyve (vlapic) contains a data structure isrvec_stk which tracks the vectors of delivered interrupts for the purpose of asserting certain invariants. While the use of ifdef around pieces relating to isrvec_stk might make it seem as if it's just an additional check on top of the standard logic, it is (via vlapic_update_ppr) load bearing. The same data could be effectively derived from the isr0-7 registers in the LAPIC page. Considering that the state contained in isrvec_stk is a bhyve implementation detail, rather than architecturally defined, it would be nice if it could be omitted. This is especially true for save/restore or live-migrate cases, where that isrvec_stk data would need to be rehydrated and/or its checks disabled, lest the new host running the VM fail an assert because the architectural and implementation states differ.

The logic itself could be kept around for debugging purposes, but in a way that makes it optional.

History

#1

Updated by Electric Monk 30 days ago

  • Gerrit CR set to 799
#2

Updated by Joshua M. Clulow 29 days ago

  • Description updated (diff)
#3

Updated by Patrick Mooney 14 days ago

It seems that few OSes use nested interrupt priorities these days. While illumos uses the TPR (unlike Linux) to elevate thread priority during an interrupt, it does immediately EOI vectors, using the TPR to set priority rather than the active ISR. OpenBSD, as it turns out, does still use the priority set by ISR in addition to allowing interrupt preemption. By testing it with APICv features turned off, it was an opportunity to verify that both the "hot path" EOI vector selection works, as well as the optional isrvec_stk logic. All of this appeared to be working fine while driving both disk and network loads in an OpenBSD 6.7 VM. With dtrace, I could see that isrvec_stk_top in the debug/verification logic rose as high as 3, indicating two preempted ISRs.

Also available in: Atom PDF