Actions
Bug #15326
openbhyve vrtc fails ASSERT after migration
Status:
New
Priority:
Normal
Assignee:
-
Category:
bhyve
Start date:
Due date:
% Done:
0%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:
Description
While running some live-migration tests on a machine with DEBUG bits installed, bhyve tripped over this assertion as part of the tests:
panic[cpu27]/thread=fffffe59f805ebc0: assertion failed: delta >= 0 (0xffffffff3a7fe710 >= 0x0), file: ../../intel/io/vmm/io/vrtc.c, line: 158 fffffe007e7c9790 fffffffffbdcb7c1 () fffffe007e7c97d0 vmm:vrtc_curtime+fa () fffffe007e7c9810 vmm:vrtc_data_write+ea () fffffe007e7c9870 vmm:vmm_data_write+87 () fffffe007e7c9c30 vmm:vmmdev_do_ioctl+3198 () fffffe007e7c9cb0 vmm:vmm_ioctl+143 () fffffe007e7c9cf0 genunix:cdev_ioctl+2b () fffffe007e7c9d40 specfs:spec_ioctl+45 () fffffe007e7c9dd0 genunix:fop_ioctl+5b () fffffe007e7c9ef0 genunix:ioctl+153 () fffffe007e7c9f00 unix:brand_sys_syscall+304 ()
The ASSERT in question is basically checking that time in the vrtc is proceeding forward:
static time_t
vrtc_curtime(struct vrtc *vrtc, hrtime_t *basetime)
{
time_t t = vrtc->base_rtctime;
hrtime_t base = vrtc->base_uptime;
ASSERT(VRTC_LOCKED(vrtc));
if (update_enabled(vrtc)) {
const hrtime_t delta = gethrtime() - vrtc->base_uptime;
const time_t sec = delta / NANOSEC;
ASSERT3S(delta, >=, 0);
t += sec;
base += sec * NANOSEC;
}
if (basetime != NULL) {
*basetime = base;
}
return (t);
}
In the face of being able to set base_uptime
as part of the save/restore functionality, we should evaluate what limits should be put in place to either fulfill this invariant, or to restructure things so the ASSERT and any involved logic can safely handle such circumstances.
Related issues
Actions