Project

General

Profile

Actions

Bug #15326

open

bhyve vrtc fails ASSERT after migration

Added by Patrick Mooney 2 months ago. Updated 8 days ago.

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

Related to illumos gate - Bug #15314: bhyve state restore should be safeNew

Actions
Related to illumos gate - Bug #15462: bhyve rtc lacks precision beyond secondsIn ProgressPatrick Mooney

Actions
Actions #1

Updated by Patrick Mooney 2 months ago

  • Related to Bug #15314: bhyve state restore should be safe added
Actions #2

Updated by Patrick Mooney 22 days ago

  • Related to Bug #15462: bhyve rtc lacks precision beyond seconds added
Actions #3

Updated by Electric Monk 8 days ago

  • Gerrit CR set to 2734
Actions #4

Updated by Patrick Mooney 8 days ago

The work in #15462 overhauls the in-kernel representation of the RTC state, and thus addresses the assertion in question, since the means by which base_clock is populated are different and more thorough when it comes to verification.

Actions

Also available in: Atom PDF