Project

General

Profile

Actions
Copy link

Bug #12922

closed

bhyve vmm ops could have stronger guardrail

Added by Patrick Mooney about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Low
Assignee:
Patrick Mooney
Category:
bhyve
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
771
External Bug:

Description

When bhyve is initialized, it chooses a vmm_ops set, based on the physical CPU (Intel or AMD) it's running on. The macros which call into this struct have explicit checks for it being non-NULL, which should never be possible given our guards anyways. To simplify those macros and maintain the safety, we could populate a null-ish vmm_ops struct with functions that simply panic.

Actions
Copy link
 #1

Updated by Patrick Mooney about 3 years ago

This is just a minor clean-up, and considering it's already a well-protected error case, should not be at all visible to a system.

Actions
Copy link
 #2

Updated by Electric Monk about 3 years ago

  • Gerrit CR set to 771
Actions
Copy link
 #3

Updated by Patrick Mooney about 3 years ago

I've tested this on AMD and Intel systems to confirm that bhyve loads properly and is able to start VMs without issue.

Actions
Copy link
 #4

Updated by Electric Monk about 3 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit b38fc3ed80ecaf16c46433e690e6f17495c5e179

commit  b38fc3ed80ecaf16c46433e690e6f17495c5e179
Author: Patrick Mooney <pmooney@pfmooney.com>
Date:   2020-07-13T17:20:06.000Z

    12922 bhyve vmm ops could have stronger guardrail
    Reviewed by: Andy Fiddaman <andy@omniosce.org>
    Reviewed by: Mike Zeller <mike.zeller@joyent.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions
Copy link

Also available in: Atom PDF