Project

General

Profile

Actions

Bug #14012

closed

vioif simply cannot without SMBIOS

Added by Joshua M. Clulow 4 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Category:
driver - device drivers
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

When the system does not provide an SMBIOS table, vioif presently panics while attempting to determine which hypervisor is in use. When there is no table, ksmbios is NULL; other callers in the kernel do an explicit NULL check before making calls, and so should vioif.


Related issues

Related to illumos gate - Bug #12015: vioif with MSI-X not working on Google Compute EngineClosedJoshua M. Clulow

Actions
Actions #1

Updated by Joshua M. Clulow 4 months ago

  • Related to Bug #12015: vioif with MSI-X not working on Google Compute Engine added
Actions #2

Updated by Joshua M. Clulow 4 months ago

The panic looks like:

panic[cpu1]/thread=fffffe00050c7c20: BAD TRAP: type=e (#pf Page fault) rp=fffffe00050c7740 addr=40 occurred in module "unix" due to a NULL pointer dereference

sched: #pf Page fault
Bad kernel fault at addr=0x40
pid=0, pc=0xfffffffffb8707c1, sp=0xfffffe00050c7830, eflags=0x10282
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe>  cr4: 406b8<osxsav,xmme,fxsr,pge,pae,pse,de>
cr2: 40  cr3: 22800000  cr8: 0

        rdi:                0 rsi:                1 rdx: fffffe00050c7c20
        rcx:                0  r8:                0  r9:                0
        rax:         ffffffff rbx: fffffe03845e49c0 rbp: fffffe00050c7880
        r10:         c0000000 r11:                0 r12: fffffe00050c7890
        r13: fffffe0384b00a80 r14: fffffe03826c6b48 r15: fffffe03826c6b48
        fsb:                0 gsb: fffffe0383da0000  ds:               4b
         es:               4b  fs:                0  gs:              1c3
        trp:                e err:                0 rip: fffffffffb8707c1
         cs:               30 rfl:            10282 rsp: fffffe00050c7830
         ss:               38

Warning - stack not written to the dump buffer
fffffe00050c7640 unix:die+c6 ()
fffffe00050c7730 unix:trap+1169 ()
fffffe00050c7740 unix:cmntrap+e9 ()
fffffe00050c7880 unix:smb_lookup_type+1 ()
fffffe00050c78f0 vioif:vioif_select_interrupt_types+40 ()
fffffe00050c7950 vioif:vioif_attach+e0 ()
fffffe00050c79d0 genunix:devi_attach+a1 ()
fffffe00050c7a10 genunix:attach_node+8b ()
fffffe00050c7a60 genunix:i_ndi_config_node+12c ()
fffffe00050c7a90 genunix:i_ddi_attachchild+3a ()
fffffe00050c7ad0 genunix:devi_attach_node+5d ()
fffffe00050c7b50 genunix:config_immediate_children+d0 ()
fffffe00050c7ba0 genunix:devi_config_common+69 ()
fffffe00050c7c00 genunix:mt_config_thread+13a ()
fffffe00050c7c10 unix:thread_start+b ()

skipping system dump - no dump device configured
rebooting...
Actions #3

Updated by Joshua M. Clulow 4 months ago

Testing Notes

I built an ISO with a ramdisk that included this change, and booted it under Propolis which does not presently expose an SMBIOS table to guests:

# mdb -ke 'ksmbios/p'
ksmbios:
ksmbios:        0

There was no longer a panic, and I was able to attach and use vioif0 to set up the VM.

I also booted the final RTI build in a KVM/QEMU guest using vioif but where SMBIOS is available to confirm things still work as they did before.

Actions #4

Updated by Joshua M. Clulow 4 months ago

  • Gerrit CR set to 1650
Actions #5

Updated by Electric Monk 4 months ago

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

git commit f2047739583ce5779dd354aec92a3f683e1d1014

commit  f2047739583ce5779dd354aec92a3f683e1d1014
Author: Joshua M. Clulow <josh@sysmgr.org>
Date:   2021-08-11T23:22:50.000Z

    14012 vioif simply cannot without SMBIOS
    Reviewed by: Andy Fiddaman <andy@omnios.org>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Approved by: Robert Mustacchi <rm@fingolfin.org>

Actions

Also available in: Atom PDF