Bug 276421 - Commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6 inhibits initialization of Xen front and backends
Summary: Commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6 inhibits initialization of Xe...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 15.0-CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Roger Pau Monné
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2024-01-18 13:43 UTC by Trond Endrestøl
Modified: 2024-02-27 08:37 UTC (History)
2 users (show)

See Also:


Attachments
Custom kernel configuration file XENGUEST (3.37 KB, text/plain)
2024-01-18 13:43 UTC, Trond Endrestøl
no flags Details
Boot messages related to commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, part 1 of 3 (431.86 KB, image/png)
2024-01-18 17:56 UTC, Trond Endrestøl
no flags Details
Boot messages related to commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, part 2 of 3 (428.97 KB, image/png)
2024-01-18 17:57 UTC, Trond Endrestøl
no flags Details
Boot messages related to commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, part 3 of 3 (344.42 KB, image/png)
2024-01-18 17:57 UTC, Trond Endrestøl
no flags Details
Proposed fix (2.09 KB, patch)
2024-01-19 09:27 UTC, Roger Pau Monné
no flags Details | Diff
Patch v2 (2.73 KB, patch)
2024-01-19 16:47 UTC, Roger Pau Monné
no flags Details | Diff
Patch v3 (13.56 KB, patch)
2024-01-23 09:12 UTC, Roger Pau Monné
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Trond Endrestøl 2024-01-18 13:43:13 UTC
Created attachment 247741 [details]
Custom kernel configuration file XENGUEST

Without backing out commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, a XENGUEST kernel for amd64 15.0-CURRENT has no disks (ada[0-2], xbd[4-n]) and probably no NICs (xn[0-n]) at boot time on XCP-ng 8.2.1. Custom kernel configuration file is attached in case the problem is there instead.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2024-01-18 15:22:52 UTC
^Triage: to submitter: please let us know which file b0165dc4539fdfc84351a719b58850e4e7a6cbb6 affected.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2024-01-18 16:00:35 UTC
(In reply to Mark Linimon from comment #1)
Never mind, I have looked it up as sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c 2024-01-16 royger.
Comment 3 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-18 16:55:30 UTC
(In reply to Trond Endrestøl from comment #0)
Can you also paste the FreeBSD dmesg?

My guess is that XCP-ng enables viridian extensions for FreeBSD guests, and that causes the Hypervisor Origin to be detected as "Microsoft Hv" instead of Xen.

I will see about making this better, but ultimately this is XCP-ng fault for exposing viridian extensions to FreeBSD guests.  Which guest template are you using?
Comment 4 Trond Endrestøl 2024-01-18 17:19:31 UTC
(In reply to Roger Pau Monné from comment #3)
I used the “Other Install Media” template as none of the other templates seemed more suitable.
I'll see if I can produce a dmesg, or at least screenshots of the boot messages. Do you want/need verbose boot messages?
Comment 5 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-18 17:25:35 UTC
(In reply to Trond Endrestøl from comment #4)
I see, yes, IIRC the “Other Install Media” enables viridian extensions for some weird reason.
Comment 6 Gleb Smirnoff freebsd_committer freebsd_triage 2024-01-18 17:26:20 UTC
Assign to author of the regressing commit.
Comment 7 Trond Endrestøl 2024-01-18 17:56:51 UTC
Created attachment 247748 [details]
Boot messages related to commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, part 1 of 3
Comment 8 Trond Endrestøl 2024-01-18 17:57:14 UTC
Created attachment 247749 [details]
Boot messages related to commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, part 2 of 3
Comment 9 Trond Endrestøl 2024-01-18 17:57:35 UTC
Created attachment 247750 [details]
Boot messages related to commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, part 3 of 3
Comment 10 Trond Endrestøl 2024-01-19 08:25:41 UTC
I tried disabling the Viridian extensions, but the kernel never got running, I only got a blank screen, and in the end the VM rebooted.

xe vm-list | less -SX#1
...
uuid ( RO)           : b918b868-9065-40bc-73fa-6b16b57308aa
     name-label ( RW): FreeBSD/amd64 src/main ZFS UEFI
    power-state ( RO): running

xe vm-param-set uuid=b918b868-9065-40bc-73fa-6b16b57308aa platform:viridian=false

The same trick was harmless to an OpenBSD VM I have running in a different XCP-ng pool.

I had to stop and start the FreeBSD VM after setting viridian=true.
Comment 11 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-19 08:40:53 UTC
(In reply to Trond Endrestøl from comment #10)
That's weird.  I'm using upstream Xen (with xl toolstack instead of XAPI), and current FreeBSD does work fine with viridian=0 (the default).  Even with viridian=1 it does boot, but uses the emulated IO devices instead of the PV ones.  I'm working on a patch right now to revert to previous behavior (so that Xen detection overrules HyperV one).
Comment 12 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-19 09:27:44 UTC
Created attachment 247769 [details]
Proposed fix

Can you please give a try to the attached fix?  You will only need to rebuild the kernel.
Comment 13 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-19 16:47:22 UTC
Created attachment 247784 [details]
Patch v2

Updated patch, please give it a try.
Comment 14 Trond Endrestøl 2024-01-19 20:25:53 UTC
(In reply to Roger Pau Monné from comment #13)

I'm sorry, your patch v2 combined with viridian=true gave the same result as without any patch and viridian=false, a blank screen after the kernel was loaded, and a reboot some seconds later. I even tried with viridian=false, and I made sure the VM was shutdown while changing this setting, but there was no change. I'm back to the previous system where I backed out the recent patch to hvm.c and viridian is set to true.

Here are the “deep settings” for this VM:

# xe vm-list name-label='FreeBSD/amd64 src/main ZFS UEFI' params=platform
platform (MRW)    : viridian: true; timeoffset: 0; device-model: qemu-upstream-uefi; hpet: true; nx: true; secureboot: false; pae: true; apic: true; acpi: 1; cores-per-socket: 16
Comment 15 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-19 20:39:01 UTC
(In reply to Trond Endrestøl from comment #14)
Thanks for testing, I will try to reproduce on an equivalent system, as the patch works for me on current Xen upstream.  I'm also unsure why backing out just this change fixes booting, as without that change I can't boot on current Xen because the HVM detection is busted.
Comment 16 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-20 09:44:59 UTC
One further question I have, what happens if you set platform:viridian=false with b0165dc4539fdfc84351a719b58850e4e7a6cbb6 reverted, does the VM boot?
Comment 17 Trond Endrestøl 2024-01-22 08:38:17 UTC
(In reply to Roger Pau Monné from comment #16)

> One further question I have, what happens if you set platform:viridian=false with b0165dc4539fdfc84351a719b58850e4e7a6cbb6 reverted, does the VM boot?

No, it doesn't boot when platform:viridian=false and the recent changes to hvm.c is backed out, all I get is a blank screen and then the VM reboots after a few seconds. Note, this is on unpatched XCP-ng 8.2.1.
Comment 18 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-22 09:04:34 UTC
(In reply to Trond Endrestøl from comment #17)
Interesting, it seems like there's a previous issue on XCP-ng and likely XenServer when viridian=false.  Currently looking into it.
Comment 19 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-22 11:08:17 UTC
Can you provide the output of `xl info` from XCP-ng dom0?  I'm attempting to reproduce it using XenServer, but I don't seem to manage to do it (the image does boot fine with platform:viridian=false).

Could you also provide the output of `xl dmesg` from dom0?

Thanks, Roger.
Comment 20 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-22 11:17:13 UTC
OK, finally managed to reproduce this, it's the mix of UEFI + platform:viridian=false that makes the FreeBSD kernel crash.  No need for the requested xl info or xl dmesg anymore.  I expect to get this solved soon, but if you are in a hurry using BIOS instead of UEFI seems to be a workaround.
Comment 21 Trond Endrestøl 2024-01-22 12:57:37 UTC
(In reply to Roger Pau Monné from comment #20)

I'm in no particular hurry. This is purely a FreeBSD test VM, letting me know what's on the horizon within the XCP-ng environment. The same goes for the other four FreeBSD test VMs; stable/14, releng/14.0, stable/13, and releng/13.2. I prefer UEFI since the console is a lot faster than its BIOS counterpart, and having the rEFInd boot manager around has proven to be helpful in case of bugs in the boot loader.
Comment 22 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-23 09:12:32 UTC
Created attachment 247874 [details]
Patch v3

This turned out to be much more work that what I was initially expecting, but it's overall a nice cleanup IMO.  I'm attaching a single diff with all the work I've accumulated so far, if you can give it a try.
Comment 23 Trond Endrestøl 2024-01-23 19:58:51 UTC
(In reply to Roger Pau Monné from comment #22)

Success! Thank you so much. Here's the dmesg while platform:viridian=true:

---<<BOOT>>---
Copyright (c) 1992-2024 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 15.0-CURRENT #977 main+local-n246786-733e85748499-dirty: Tue Jan 23 20:48:49 CET 2024
    root@[REDACTED]:/usr/obj/usr/src/amd64.amd64/sys/XENGUEST amd64
FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)
VT(efifb): resolution 1024x768
XEN: Hypervisor version 4.13 detected.
CPU: Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz (2294.84-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x50654  Family=0x6  Model=0x55  Stepping=4
  Features=0x1fc3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT>
  Features2=0xfffa3203<SSE3,PCLMULQDQ,SSSE3,FMA,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x19c6feb<FSGSBASE,TSCADJ,BMI1,AVX2,FDPEXC,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB>
  Structured Extended Features2=0x18<PKU,OSPKE>
  Structured Extended Features3=0x9c000400<MD_CLEAR,IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  AMD Extended Feature Extensions ID EBX=0x1000<IBPB>
Hypervisor: Origin = "XenVMMXenVMM"
real memory  = 34355544064 (32764 MB)
avail memory = 33368510464 (31822 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <Xen HVM>
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
FreeBSD/SMP: 2 package(s) x 16 cache groups x 1 core(s)
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0: MADT APIC ID 1 != hw id 0
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-47
Launching APs: 13 2 20 7 12 24 9 6 11 19 27 18 21 30 23 10 15 26 14 5 25 22 16 1 3 17 31 29 8 28 4
random: entropy device external interface
kbd1 at kbdmux0
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 1.000000s
smbios0: <System Management BIOS> at iomem 0xef9cc000-0xef9cc01e
smbios0: Version: 2.8, BCD Revision: 2.8
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <Xen>
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
cpu0: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 62500000 Hz quality 950
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX3 WDMA2 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc100-0xc10f at device 1.1 on pci0
ata0: <ATA channel> at channel 0 on atapci0
ata1: <ATA channel> at channel 1 on atapci0
pci0: <serial bus, USB> at device 1.2 (no driver attached)
intsmb0: <Intel PIIX4 SMBUS Interface> irq 20 at device 1.3 on pci0
intsmb0: intr IRQ 9 enabled revision 0
smbus0: <System Management Bus> on intsmb0
vgapci0: <VGA-compatible display> mem 0xf0000000-0xf1ffffff,0xf3022000-0xf3022fff at device 2.0 on pci0
vgapci0: Boot video device
xenpci0: <Xen Platform Device> port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 15.0.
psm0: model IntelliMouse Explorer, device ID 4
xenpv0: <Xen PV bus>
granttable0: <Xen Grant-table Device> on xenpv0
xc0: <Xen Console> on xenpv0
xen_et0: <Xen PV Clock> on xenpv0
Event timer "XENTIMER" frequency 1000000000 Hz quality 950
Timecounter "XENTIMER" frequency 1000000000 Hz quality 950
xen_et0: registered as a time-of-day clock, resolution 0.000001s
xenstore0: <XenStore> on xenpv0
xsd_dev0: <Xenstored user-space device> on xenpv0
evtchn0: <Xen event channel user-space device> on xenpv0
privcmd0: <Xen privileged interface user-space device> on xenpv0
gntdev0: <Xen grant-table user-space device> on xenpv0
debug0: <Xen debug handler> on xenpv0
Timecounters tick every 20.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
xenballoon0: <Xen Balloon Device> on xenstore0
xctrl0: <Xen Control Device> on xenstore0
xs_dev0: <Xenstore user-space device> on xenstore0
xenbusb_front0: <Xen Frontend Devices> on xenstore0
xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
xn0: Ethernet address: XX:XX:XX:XX:XX:XX
xenbusb_back0: <Xen Backend Devices> on xenstore0
xn0: backend features: feature-sg feature-gso-tcp4
xbd5: 256MB <Virtual Block Device> at device/vbd/51792 on xenbusb_front0
xbd5: features: write_barrier
xbd5: synchronize cache commands enabled.
xbd0: 25600MB <Virtual Block Device> at device/vbd/5632 on xenbusb_front0
xbd0: attaching as ada2
xbd0: features: write_barrier
xbd0: synchronize cache commands enabled.
xbd4: 256MB <Virtual Block Device> at device/vbd/51776 on xenbusb_front0
xbd4: features: write_barrier
xbd4: synchronize cache commands enabled.
xbd1: 25600MB <Virtual Block Device> at device/vbd/832 on xenbusb_front0
xbd1: attaching as ada1
xbd1: features: write_barrier
xbd1: synchronize cache commands enabled.
xbd6: 17408MB <Virtual Block Device> at device/vbd/51808 on xenbusb_front0
xbd6: features: write_barrier
xbd6: synchronize cache commands enabled.
xbd2: 25600MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd2: attaching as ada0
xbd2: features: write_barrier
xbd2: synchronize cache commands enabled.
Trying to mount root from zfs:zroot/ROOT/20240123-204928-main-local-n246786-733e85748499 []...
cd0 at ata1 bus 0 scbus1 target 1 lun 0
cd0: <QEMU QEMU DVD-ROM 2.5+> Removable CD-ROM SCSI device
cd0: Serial Number QM00004
cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
Dual Console: Serial Primary, Video Secondary
lo0: link state changed to UP
xn0: performing interface reset due to feature change
xn0: backend features: feature-sg feature-gso-tcp4
xn0: performing interface reset due to feature change
xn0: backend features: feature-sg feature-gso-tcp4
xn0: link state changed to DOWN
xn0: link state changed to UP
xn0: link state changed to DOWN
xn0: link state changed to UP
Security policy loaded: MAC/ntpd (mac_ntpd)
Comment 24 Roger Pau Monné freebsd_committer freebsd_triage 2024-01-24 08:40:04 UTC
(In reply to Trond Endrestøl from comment #23)
If it's not too much trouble, can you also check if booting with platform:viridian=false works?
Comment 25 Trond Endrestøl 2024-01-24 11:32:27 UTC
(In reply to Roger Pau Monné from comment #24)

This is when viridian is set to false:

---<<BOOT>>---
Copyright (c) 1992-2024 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 15.0-CURRENT #977 main+local-n246786-733e85748499-dirty: Tue Jan 23 20:48:49 CET 2024
    root@[REDACTED]:/usr/obj/usr/src/amd64.amd64/sys/XENGUEST amd64
FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)
VT(efifb): resolution 1024x768
XEN: Hypervisor version 4.13 detected.
CPU: Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz (2294.66-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x50654  Family=0x6  Model=0x55  Stepping=4
  Features=0x1fc3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT>
  Features2=0xfffa3203<SSE3,PCLMULQDQ,SSSE3,FMA,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x19c6feb<FSGSBASE,TSCADJ,BMI1,AVX2,FDPEXC,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB>
  Structured Extended Features2=0x18<PKU,OSPKE>
  Structured Extended Features3=0x9c000400<MD_CLEAR,IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  AMD Extended Feature Extensions ID EBX=0x1000<IBPB>
Hypervisor: Origin = "XenVMMXenVMM"
real memory  = 34355544064 (32764 MB)
avail memory = 33368510464 (31822 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <Xen HVM>
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
FreeBSD/SMP: 2 package(s) x 16 cache groups x 1 core(s)
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0: MADT APIC ID 1 != hw id 0
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-47
Launching APs: 16 1 11 20 30 4 15 26 2 3 6 12 14 13 29 25 17 5 7 22 9 31 10 24 23 21 28 19 18 27 8
random: entropy device external interface
kbd1 at kbdmux0
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 1.000000s
smbios0: <System Management BIOS> at iomem 0xef9cc000-0xef9cc01e
smbios0: Version: 2.8, BCD Revision: 2.8
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <Xen>
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
cpu0: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 62500000 Hz quality 950
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX3 WDMA2 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc100-0xc10f at device 1.1 on pci0
ata0: <ATA channel> at channel 0 on atapci0
ata1: <ATA channel> at channel 1 on atapci0
pci0: <serial bus, USB> at device 1.2 (no driver attached)
intsmb0: <Intel PIIX4 SMBUS Interface> irq 20 at device 1.3 on pci0
intsmb0: intr IRQ 9 enabled revision 0
smbus0: <System Management Bus> on intsmb0
vgapci0: <VGA-compatible display> mem 0xf0000000-0xf1ffffff,0xf3022000-0xf3022fff at device 2.0 on pci0
vgapci0: Boot video device
xenpci0: <Xen Platform Device> port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 15.0.
psm0: model IntelliMouse Explorer, device ID 4
xenpv0: <Xen PV bus>
granttable0: <Xen Grant-table Device> on xenpv0
xc0: <Xen Console> on xenpv0
xen_et0: <Xen PV Clock> on xenpv0
Event timer "XENTIMER" frequency 1000000000 Hz quality 950
Timecounter "XENTIMER" frequency 1000000000 Hz quality 950
xen_et0: registered as a time-of-day clock, resolution 0.000001s
xenstore0: <XenStore> on xenpv0
xsd_dev0: <Xenstored user-space device> on xenpv0
evtchn0: <Xen event channel user-space device> on xenpv0
privcmd0: <Xen privileged interface user-space device> on xenpv0
gntdev0: <Xen grant-table user-space device> on xenpv0
debug0: <Xen debug handler> on xenpv0
Timecounters tick every 20.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
xenballoon0: <Xen Balloon Device> on xenstore0
xctrl0: <Xen Control Device> on xenstore0
xs_dev0: <Xenstore user-space device> on xenstore0
xenbusb_front0: <Xen Frontend Devices> on xenstore0
xbd4: 256MB <Virtual Block Device> at device/vbd/51776 on xenbusb_front0
xn0: <Virtual Network Interface>xbd4: features: write_barrier
xbd4: synchronize cache commands enabled.
 at device/vif/0 on xenbusb_front0
xn0: Ethernet address: XX:XX:XX:XX:XX:XX
xenbusb_back0: <Xen Backend Devices> on xenstore0
xbd6: 17408MB <Virtual Block Device> at device/vbd/51808 on xenbusb_front0
xbd6: features: write_barrier
xbd6: synchronize cache commands enabled.
xn0: backend features: feature-sg feature-gso-tcp4
xbd0: 25600MB <Virtual Block Device> at device/vbd/832 on xenbusb_front0
xbd0: attaching as ada1
xbd0: features: write_barrier
xbd0: synchronize cache commands enabled.
xbd1: 25600MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd1: attaching as ada0
xbd1: features: write_barrier
xbd1: synchronize cache commands enabled.
xbd5: 256MB <Virtual Block Device> at device/vbd/51792 on xenbusb_front0
xbd5: features: write_barrier
xbd5: synchronize cache commands enabled.
xbd2: 25600MB <Virtual Block Device> at device/vbd/5632 on xenbusb_front0
xbd2: attaching as ada2
xbd2: features: write_barrier
xbd2: synchronize cache commands enabled.
Trying to mount root from zfs:zroot/ROOT/20240123-204928-main-local-n246786-733e85748499 []...
cd0 at ata1 bus 0 scbus1 target 1 lun 0
cd0: <QEMU QEMU DVD-ROM 2.5+> Removable CD-ROM SCSI device
cd0: Serial Number QM00004
cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
Dual Console: Serial Primary, Video Secondary
lo0: link state changed to UP
xn0: performing interface reset due to feature change
xn0: backend features: feature-sg feature-gso-tcp4
xn0: performing interface reset due to feature change
xn0: backend features: feature-sg feature-gso-tcp4
xn0: link state changed to DOWN
xn0: link state changed to UP
xn0: link state changed to DOWN
xn0: link state changed to UP
Security policy loaded: MAC/ntpd (mac_ntpd)
Comment 26 commit-hook freebsd_committer freebsd_triage 2024-02-22 10:31:37 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=6744fd8e75032c893e6a80bced8be3a991fa2901

commit 6744fd8e75032c893e6a80bced8be3a991fa2901
Author:     Roger Pau Monné <royger@FreeBSD.org>
AuthorDate: 2024-01-19 09:15:17 +0000
Commit:     Roger Pau Monné <royger@FreeBSD.org>
CommitDate: 2024-02-22 10:08:04 +0000

    x86/cpu: improve hypervisor detection

    Some hypervisors can expose multiple signatures, for example Xen will expose
    both the Xen and the HyperV signatures if Viridian extensions are enabled for
    the guest.  Presence of multiple signatures is currently not handled by
    FreeBSD, that will exit once a known signature is found in cpuid output.

    Exposing the HyperV signature on hypervisors different than HyperV is not
    uncommon, this is done so that such hypervisor can expose a (subset) of the
    Viridian extensions to Windows guests for performance reasons.  Likely for
    compatibility purposes the HyperV signature is always exposed on the first
    leaf, and the Xen signature is exposed in the secondary leaf.

    Fix the specific case of HyperV by not exiting from the scan if the HyperV
    signature is found, and prefer a second signature if one is found.

    Note that long term we might wish to convert vm_guest into a bitmap, so that it
    can signal detection of multiple hypervisor interfaces.

    Fixes: b0165dc4539f ('x86/xen: fix HVM guest hypercall page setup')
    PR: 276421
    Sponsored by: Cloud Software Group
    Reviewed by: markj kib
    Differential revision: https://reviews.freebsd.org/D43508

 sys/x86/x86/identcpu.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)