> Date: Wed, 20 Dec 2023 09:30:45 +0100
> From: Henryk Paluch <hpal...@seznam.cz>
>
> Hello!
>
> Problem fixed! I resolved ACPI panic when booting OpenBSD7.4 as guest VM
> under Hyper-V Server 2012R2 in UEFI (Generation 2) mode with this simple
> patch:
>
> --- usr/src/sys/dev/acpi/dsdt.c.orig Tue Dec 19 07:49:12 2023
> +++ usr/src/sys/dev/acpi/dsdt.c Wed Dec 20 07:43:05 2023
> @@ -3742,7 +3742,7 @@
> struct acpi_dsdt *p_dsdt;
> struct acpi_q *entry;
>
> - if (strlen(rootpath) > 0)
> + if (strlen(rootpath) > 1 || ( strlen(rootpath)==1 && *rootpath != '\\')
> )
> aml_die("LoadTable: RootPathString unsupported");
> if (strlen(parameterpath) > 0)
> aml_die("LoadTable: ParameterPathString unsupported");
Ah, cool. That is a bit of a heck though. I did look into what is
needed to fix this properly. If I send you a diff, can you test it?
> The 7.4 kernel booted fine and I was able to install OpenBSD over serial
> console (I was unable to make working efifb0 console). Here are relevant
> boot messages from ACPI:
>
> cpihve0 at acpi0
> "ACPI0004" at acpi0 not configured
> "VMBus" at acpi0 not configured
> "Hyper_V_Gen_Counter_V1" at acpi0 not configured
> acpicmos0 at acpi0
> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
> acpicpu at acpi0 not configured
> pvbus0 at mainbus0: Hyper-V 6.3
> hyperv0 at pvbus0: protocol 3.0, features 0xc7f
> hyperv0: heartbeat, kvp, shutdown, timesync
> hvn0 at hyperv0 channel 12: NVS 5.0 NDIS 6.30, address 00:15:5d:00:33:03
> hvs0 at hyperv0 channel 13: scsi, protocol 6.0
> scsibus0 at hvs0: 2 targets
> sd0 at scsibus0 targ 0 lun 0: <Msft, Virtual Disk, 1.0>
> naa.600224806339816dd00df20d64df290b
> sd0: 20480MB, 512 bytes/sector, 41943040 sectors, thin
> sd1 at scsibus0 targ 0 lun 1: <Msft, Virtual Disk, 1.0>
> naa.60022480d40507eafb74508ae0298284
> sd1: 664MB, 512 bytes/sector, 1360832 sectors, thin
> pci0 at mainbus0 bus 0
> isa0 at mainbus0
> efifb0 at mainbus0: 1024x768, 32bpp
> wsdisplay at efifb0 not configured
> softraid0 at root
> scsibus1 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
>
>
> Unpatched kernel panics on this:
>
> > acpihve0 at acpi0
> > LoadTable: RootPathString unsupported
> > 0034 Called: \_SB_._INI
> > 0034 Called: \_SB_._INI
> > panic: aml_die aml_loadtable:3746
>
> Here is relevant part of DSDT ACPI table that causes panic on stock
> kernel (dumped and decompiled on similar Linux guest with Intel acpi tools):
>
> /*
> * Intel ACPI Component Architecture
> * AML/ASL+ Disassembler version 20220331 (64-bit version)
> * Copyright (c) 2000 - 2022 Intel Corporation
> *
> * Disassembling to symbolic ASL+ operators
> *
> * Disassembly of dsdt.dat, Tue Dec 19 19:55:19 2023
> *
> * Original Table Header:
> * Signature "DSDT"
> * Length 0x00000D8E (3470)
> * Revision 0x02
> * Checksum 0x65
> * OEM ID "MSFTVM"
> * OEM Table ID "DSDT01"
> * OEM Revision 0x00000001 (1)
> * Compiler ID "MSFT"
> * Compiler Version 0x04000000 (67108864)
> */
> DefinitionBlock ("", "DSDT", 2, "MSFTVM", "DSDT01", 0x00000001)
> {
> Scope (_SB)
> {
> Method (_INI, 0, NotSerialized) // _INI: Initialize
> {
> If ((SCFG > Zero))
> {
> LoadTable ("OEM1", "MSFTVM", "UARTS", "\\", "", Zero)
> }
>
> If ((BFLG & 0x02))
> {
> LoadTable ("OEMP", "MSFTVM", "SPCI", "\\", "", Zero)
> }
> }
> }
>
> OperationRegion (BIOS, SystemMemory, 0x7FDD7000, 0xFF)
> Field (BIOS, ByteAcc, NoLock, Preserve)
> ....
>
>
> Personally I'm fine with that solution. Hoping that it may help anybody
> else using OpenBSD on Hyper-V Gen2 mode.
>
> Best regards
> --Henryk Paluch
>
>
> On 12/19/23 18:36, Henryk Paluch wrote:
> > Hello!
> >
> > I was able to gather additional information - using small path for stock
> > OpenBSD 7.4/amd64 kernel to print few debug messages. Additionally I
> > used ACPI tools under Linux guest (under same Hyper-V in UEFI mode) to
> > get details on ACPI tables.
> >
> > The kernel patch is this primitive:
> >
> > diff -u /usr/src/sys/dev/acpi/dsdt.c{.orig,}
> > --- /usr/src/sys/dev/acpi/dsdt.c.orig Tue Dec 19 07:49:12 2023
> > +++ /usr/src/sys/dev/acpi/dsdt.c Tue Dec 19 17:59:29 2023
> > @@ -3742,11 +3742,23 @@
> > struct acpi_dsdt *p_dsdt;
> > struct acpi_q *entry;
> >
> > - if (strlen(rootpath) > 0)
> > - aml_die("LoadTable: RootPathString unsupported");
> > + printf("HP4\n");
> > + if (strlen(rootpath) > 0){
> > + aml_showvalue(parameterdata);
> > + aml_die("LoadTable: RootPathString unsupported: rootpath='%s', "
> > + "sign='%s', oemid='%s', oemtableid='%s', "
> > + "ppath='%s'\n",
> > + rootpath, signature, oemid, oemtableid, parameterpath);
> > + }
> > if (strlen(parameterpath) > 0)
> > aml_die("LoadTable: ParameterPathString unsupported");
> >
> > + printf("%s:%d OK: Processing rootpath='%s', "
> > + "sign='%s', oemid='%s', oemtableid='%s', "
> > + "ppath='%s'\n",
> > + __func__,__LINE__,
> > + rootpath, signature, oemid, oemtableid, parameterpath);
> > + aml_showvalue(parameterdata);
> > SIMPLEQ_FOREACH(entry, &sc->sc_tables, q_next) {
> > hdr = entry->q_table;
> > if (strncmp(hdr->signature, signature,
> >
> >
> > Here is what I see on console output right before panic (what is strange
> > that it seems to be first call to aml_loadtable() function):
> >
> > acpihve0 at acpi0
> > HP4
> > 0xffff800000041608 cnt:01 stk:00 integer: 0
> > LoadTable: RootPathString unsupported: rootpath='\', sign='OEM1',
> > oemid='MSFTVM', oemtableid='UARTS', ppath=''
> >
> > 0034 Called: \_SB_._INI
> > 0034 Called: \_SB_._INI
> > panic: aml_die aml_loadtable:3751
> > Stopped at db_enter+0x14: popq %rbp
> >
> > Using acpidump and iasl under Linux guest (same Hyper-V and also in UEFI
> > mode) I got these details of OEM1 table:
> >
> > OEM1 @ 0x0000000000000000
> > 0000: 4F 45 4D 31 9E 00 00 00 02 92 4D 53 46 54 56 4D OEM1......MSFTVM
> > 0010: 55 41 52 54 53 00 00 00 01 00 00 00 4D 53 46 54 UARTS.......MSFT
> > 0020: 00 00 00 04 10 49 07 5F 53 42 5F 5B 82 37 55 41 .....I._SB_[.7UA
> > 0030: 52 31 08 5F 48 49 44 0C 41 D0 05 01 08 5F 44 44 R1._HID.A...._DD
> > 0040: 4E 0D 43 4F 4D 31 00 08 5F 55 49 44 01 08 5F 43 N.COM1.._UID.._C
> > 0050: 52 53 11 11 0A 0E 23 10 00 01 47 01 F8 03 F8 03 RS....#...G.....
> > 0060: 01 08 79 00 5B 82 38 55 41 52 32 08 5F 48 49 44 ..y.[.8UAR2._HID
> > 0070: 0C 41 D0 05 01 08 5F 44 44 4E 0D 43 4F 4D 32 00 .A...._DDN.COM2.
> > 0080: 08 5F 55 49 44 0A 02 08 5F 43 52 53 11 11 0A 0E ._UID..._CRS....
> > 0090: 23 08 00 01 47 01 F8 02 F8 02 01 08 79 00 #...G.......y.
> >
> > And here is output of iasl decompiler:
> >
> > /*
> > * Intel ACPI Component Architecture
> > * AML/ASL+ Disassembler version 20220331 (64-bit version)
> > * Copyright (c) 2000 - 2022 Intel Corporation
> > *
> > * Disassembling to symbolic ASL+ operators
> > *
> > * Disassembly of oem1.dat, Tue Dec 19 17:44:02 2023
> > *
> > * Original Table Header:
> > * Signature "OEM1"
> > * Length 0x0000009E (158)
> > * Revision 0x02
> > * Checksum 0x92
> > * OEM ID "MSFTVM"
> > * OEM Table ID "UARTS"
> > * OEM Revision 0x00000001 (1)
> > * Compiler ID "MSFT"
> > * Compiler Version 0x04000000 (67108864)
> > */
> > DefinitionBlock ("", "OEM1", 2, "MSFTVM", "UARTS", 0x00000001)
> > {
> > Scope (_SB)
> > {
> > Device (UAR1)
> > {
> > Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM
> > Serial Port */) // _HID: Hardware ID
> > Name (_DDN, "COM1") // _DDN: DOS Device Name
> > Name (_UID, One) // _UID: Unique ID
> > Name (_CRS, ResourceTemplate () // _CRS: Current Resource
> > Settings
> > {
> > IRQ (Edge, ActiveHigh, Exclusive, )
> > {4}
> > IO (Decode16,
> > 0x03F8, // Range Minimum
> > 0x03F8, // Range Maximum
> > 0x01, // Alignment
> > 0x08, // Length
> > )
> > })
> > }
> >
> > Device (UAR2)
> > {
> > Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM
> > Serial Port */) // _HID: Hardware ID
> > Name (_DDN, "COM2") // _DDN: DOS Device Name
> > Name (_UID, 0x02) // _UID: Unique ID
> > Name (_CRS, ResourceTemplate () // _CRS: Current Resource
> > Settings
> > {
> > IRQ (Edge, ActiveHigh, Exclusive, )
> > {3}
> > IO (Decode16,
> > 0x02F8, // Range Minimum
> > 0x02F8, // Range Maximum
> > 0x01, // Alignment
> > 0x08, // Length
> > )
> > })
> > }
> > }
> > }
> >
> > Summary:
> > It seems (confirmed from Linux guest kernel messages) that Hyper-V
> > always exposes 2 serial ports (I configured Pipe only for 1st port!) in
> > ACPI table OEM1, which current OpenBSD kernel is unable to process for
> > some reason. However I'm too new to ACPI to understand what is the problem.
> >
> > Please let me know if I can provide any additional details to resolve
> > this problem.
> >
> > Best regards
> > --Henryk Paluch
> >
> >
> > On 12/18/23 16:51, Henryk Paluch wrote:
> >> Hello!
> >>
> >> While playing with GENERIC 7.4/amd64 (install74.img) under various
> >> UEFI environments (works fine under both Proxmox/KVM and LibVirt/KVM
> >> with i440fx machine) I had accidentally found that under Hyper-V/UEFI
> >> kernel panics on early ACPI enumeration (originally I thought that it
> >> was efifb0 console bug, because it was empty, but it was not that
> >> case...).
> >>
> >> Most important messages:
> >>
> >> acpihve0 at acpi0
> >> LoadTable: RootPathString unsupported
> >> 0034 Called: \_SB_._INI
> >> 0034 Called: \_SB_._INI
> >> panic: aml_die aml_loadtable:3746
> >>
> >>
> >>
> >> Please first let me know if OpenBSD7.4 is supposed to work under
> >> Hyper-V in UEFI mode - it seems that there already exist all necessary
> >> PV devices to run as Gen2, but I was unable not find official stance
> >> on that.
> >>
> >>
> >>
> >> Environment details:
> >> - Host OS: Windows Server 2012R2 Standard with Hyper-V role and
> >> Hyper-V Manager
> >> - Guest OS: Openbsd7.4/amd64, official
> >> https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/install74.img
> >> - VM running as Generation 2 (UEFI, secure boot disabled - see below).
> >>
> >> How to reproduce
> >> ----------------
> >>
> >> 1. Download official installation image from:
> >> https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/install74.img
> >>
> >> 2. Convert it to VHDX using command like:
> >>
> >> qemu-img convert -p -f raw -O vhdx install74.img obsd74-uefi.vhdx
> >>
> >> 3. Under Hyper-V Create Generation 2 (UEFI) VM and attach above VHDX
> >> file as existing disk
> >>
> >> 4. disable Secure Boot under Firmware
> >>
> >> 5. before starting VM create Virtual COM port to see messages and
> >> panic, run this command in PowerShell:
> >>
> >> Set-VMComPort VM_NAME 1 \\.\pipe\HyperPipe
> >>
> >> 6. now start VM and press space to halt at boot> prompt
> >>
> >> 7. run Putty and select connection type `Serial` and
> >> enter `\\.\pipe\HyperPipe` as `Serial line` name (you can keep
> >> speed 9600 - it does not matter for pipes)
> >>
> >> 8. now back on Hyper-V in `boot>` type:
> >>
> >> set tty com0
> >>
> >> 9. you should see now boot> prompt in Putty.
> >>
> >> 10. now boot full GENERIC kernel (to have DDB trace - therefore bsd.rd
> >> will not help much) using this command:
> >>
> >> boot 7.4/amd64/bsd
> >>
> >> 11. after while you should see early boot messages and panic.
> >>
> >> boot> boot 7.4/amd64/bsd
> >> cannot open hd0a:/etc/random.seed: No such file or directory
> >> booting hd0a:7.4/amd64/bsd: 17163596+4137992+363792+0+1236992
> >> [1342507+128+13178 40+1011174]=0x1959a68
> >> entry point at 0x1001000
> >> [ using 3672680 bytes of bsd ELF symbol table ]
> >> Copyright (c) 1982, 1986, 1989, 1991, 1993
> >> The Regents of the University of California. All rights
> >> reserved.
> >> Copyright (c) 1995-2023 OpenBSD. All rights reserved.
> >> https://www.OpenBSD.org
> >>
> >> OpenBSD 7.4 (GENERIC) #1336: Tue Oct 10 08:52:22 MDT 2023
> >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> >> real mem = 1036947456 (988MB)
> >> avail mem = 985939968 (940MB)
> >> random: good seed from bootblocks
> >> mpath0 at root
> >> scsibus0 at mpath0: 256 targets
> >> mainbus0 at root
> >> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x3fdf1000 (12 entries)
> >> bios0: vendor Microsoft Corporation version "Hyper-V UEFI Release
> >> v1.0" date 11/ 26/2012
> >> bios0: Microsoft Corporation Virtual Machine
> >> efi0 at bios0: UEFI 2.3.1
> >> efi0: EDK II rev 0x10000
> >> acpi0 at bios0: ACPI 4.0
> >> acpi0: sleep states S0 S5
> >> acpi0: tables DSDT FACP APIC OEM0 WAET OEM1 SRAT BGRT
> >> acpi0: wakeup devices
> >> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> >> acpimadt0 at acpi0 addr 0xfee00000
> >> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 24 pins
> >> cpu0 at mainbus0: apid 0 (boot processor)
> >> cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2000.27 MHz,
> >> 0f-4b-02
> >> cpu0:
> >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
> >> LUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,HV,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG
> >> ,AMCR8
> >> cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
> >> cpu0: 512KB 64b/line 16-way L2 cache
> >> cpu0: smt 0, core 0, package 0
> >> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> >> cpu0: apic clock running at 200MHz
> >> acpihve0 at acpi0
> >> LoadTable: RootPathString unsupported
> >> 0034 Called: \_SB_._INI
> >> 0034 Called: \_SB_._INI
> >> panic: aml_die aml_loadtable:3746
> >> Stopped at db_enter+0x14: popq %rbp
> >> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> >> * 0 0 0 0x10000 0x200 0 swapper
> >> db_enter(10,ffffffff829605c0,286,8,ffffffff81835b24,ffffffff829605c0)
> >> at db_enter+0x14
> >> panic(ffffffff820e210e,ffffffff820e210e,ffffffff8209b736,ea2,ffffffff824a18c2,ffffffff829605d0)
> >> at panic+0xbc
> >> _aml_die(ffffffff8209b736,ea2,ffffffff820c2fd5,ffffffff8209b736,ffff80000002e148,ffff80000002e158)
> >> at _aml_die+0x3e7
> >> aml_loadtable(ffff800000029400,ffff80000002e138,ffff80000002e148,ffff80000002e158,ffff80000002e168,ffff80000002e178)
> >> at aml_loadtable+0x1f0
> >> aml_parse(ffff800000041088,54,ffff800000041088,ffff800000041088,8b6e818bf00372aa,ffff800000041088)
> >> at aml_parse+0xab5
> >> aml_eval(0,ffff800000030288,74,0,0,0)
> >> at aml_eval+0x301
> >> aml_evalnode(ffff800000029400,ffff800000030208,0,0,0,ffff800000029400)
> >> at aml_evalnode+0xb8
> >> acpi_inidev(ffff800000030208,ffff800000029400,50be2c891493ae1a,ffffffff81db7b50,ffff800000029400,ffffffff820ce20b)
> >> at acpi_inidev+0x6e
> >> aml_find_node(ffff80000002be08,ffffffff820ce20b,ffffffff81db7b50,ffff800000029400,3f2da558de4bb6c9,ffffffff81db7b50)
> >> at aml_find_node+0x84
> >> aml_find_node(ffffffff825679c0,ffffffff820ce20b,ffffffff81db7b50,ffff800000029400,3f2da558dee5b49f,ffffffff82960a80)
> >> at aml_find_node+0xd1
> >> acpi_attach_common(ffff800000029400,3fdfa014,be11230416b4dc44,ffff80000002b500,ffffffff82960ca0,ffffffff824951a0)
> >> at acpi_attach_common+0x607
> >> config_attach(ffff80000002b500,ffffffff824a9470,ffffffff82960ca0,ffffffff81cefcc0,1be10fea7e145b1d,ffffffff82960c60)
> >> at config_attach+0x1f4
> >> bios_attach(ffff80000002b480,ffff80000002b500,ffffffff82960dc8,ffff80000002b480,a29e677d6a51afb1,ffff80000002b480)
> >> at bios_attach+0x77e
> >> config_attach(ffff80000002b480,ffffffff824a3970,ffffffff82960dc8,ffffffff819ccb70,1be10fea7e467a4f,ffffffff82960dc8)
> >> at config_attach+0x1f4
> >> end trace frame: 0xffffffff82960e70, count: 0
> >> https://www.openbsd.org/ddb.html describes the minimum info required
> >> in bug
> >> reports. Insufficient info makes it difficult to find and fix bugs.
> >> ddb>
> >> ddb> show panic
> >> *cpu0: aml_die aml_loadtable:3746
> >>
> >> Best regards
> >> --Henryk Paluch
> >>
>
>
