Project

General

Profile

Actions

Bug #15314

open

bhyve state restore should be safe

Added by Patrick Mooney 29 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

When save/restore of kernel device state was added to bhyve in #14261, the ability to restore (read: import) state into devices was guarded with a default-off variable switch vmm_allow_state_writes. This was done with the assumption that there would be lingering bugs in and exposed by the ability to import device state. Keeping it as opt-in via mdb -kw meant that we could move forward with integration, and then remove that guard once confidence had been built around that state importation and the emulation logic impacted by it. A few bugs have been found so far (#15118 , #15312, #15251). Once all of those are addressed, it is worth considering the removal of the vmm_allow_state_writes guard, or at least changing it to default-allow.


Related issues

Related to illumos gate - Bug #15118: bhyve too strict over vmm_data lengthsClosedPatrick Mooney

Actions
Related to illumos gate - Bug #15312: bhyve has overzealous vlapic ID checkClosedPatrick Mooney

Actions
Related to illumos gate - Bug #15251: panic in vlapic_get_ccr after live migrationClosedPatrick Mooney

Actions
Related to illumos gate - Bug #15326: bhyve vrtc fails ASSERT after migrationNew

Actions
Actions #1

Updated by Patrick Mooney 22 days ago

  • Related to Bug #15118: bhyve too strict over vmm_data lengths added
Actions #2

Updated by Patrick Mooney 22 days ago

  • Related to Bug #15312: bhyve has overzealous vlapic ID check added
Actions #3

Updated by Patrick Mooney 22 days ago

  • Related to Bug #15251: panic in vlapic_get_ccr after live migration added
Actions #4

Updated by Patrick Mooney 22 days ago

  • Related to Bug #15326: bhyve vrtc fails ASSERT after migration added
Actions

Also available in: Atom PDF