Re: detecting qemu/HVF on Apple M1 silicon

Ronald Klop wrote this message on Tue, Feb 14, 2023 at 10:24 +0100:
> Van: John-Mark Gurney <jmg@funkthat.com>
> Datum: dinsdag, 14 februari 2023 09:05
> Aan: freebsd-arm@FreeBSD.org
> Onderwerp: detecting qemu/HVF on Apple M1 silicon
> > 
> > I managed to get FreeBSD running via qemu on Apple M1 silicon, but out
> > of the box vm detection isn't working causing hz to be set to 1000, and
> > causing lots of cpu usage to happen.
> > 
> > What are the recommended ways to detect this, so we can get vm_guest set?
> > 
> > A little poking around, shows that there's an ACPI device that is
> > promising:
> >         Device (FWCF)
> >         {
> >             Name (_HID, "QEMU0002")  // _HID: Hardware ID
> >             Name (_STA, 0x0B)  // _STA: Status
> >             Name (_CCA, One)  // _CCA: Cache Coherency Attribute
> >             Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
> >             {
> >                 Memory32Fixed (ReadWrite,
> >                     0x09020000,         // Address Base
> >                     0x00000018,         // Address Length
> >                     )
> >             })
> >         }
> > 
> > Here's a complete list of _HID's:
> > # acpidump -d | grep _HID | sort -u
> >                 Name (_HID, "PNP0C02" /* PNP Motherboard Resources */)  // _HID: Hardware ID
> >                 Name (_HID, "PNP0C0F" /* PCI Interrupt Link Device */)  // _HID: Hardware ID
> >             Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
> >             Name (_HID, "ACPI0013" /* Generic Event Device */)  // _HID: Hardware ID
> >             Name (_HID, "ARMH0011")  // _HID: Hardware ID
> >             Name (_HID, "LNRO0005")  // _HID: Hardware ID
> >             Name (_HID, "PNP0A08" /* PCI Express Bus */)  // _HID: Hardware ID
> >             Name (_HID, "PNP0C0C" /* Power Button Device */)  // _HID: Hardware ID
> >             Name (_HID, "QEMU0002")  // _HID: Hardware ID
> > 
> > There's also the usual virtio devices as well.
> > # pciconf -l
> > hostb0@pci0:0:0:0:  class=0x060000 rev=0x00 hdr=0x00 vendor=0x1b36 device=0x0008 subvendor=0x1af4 subdevice=0x1100
> > virtio_pci0@pci0:0:1:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1000 subvendor=0x1af4 subdevice=0x0001
> > virtio_pci1@pci0:0:2:0: class=0x038000 rev=0x01 hdr=0x00 vendor=0x1af4 device=0x1050 subvendor=0x1af4 subdevice=0x1100
> > xhci0@pci0:0:3:0:   class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x1b36 device=0x000d subvendor=0x1af4 subdevice=0x1100
> > none0@pci0:0:4:0:   class=0x040300 rev=0x01 hdr=0x00 vendor=0x8086 device=0x2668 subvendor=0x1af4 subdevice=0x1100
> > virtio_pci2@pci0:0:5:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002
> 
> I'm using UTM as a wrapper around qemu. This gives me the following in dmesg which might be a good hint.
> acpi0: <BOCHS BXPC>
> 
> "BOCHS" is also in the output of kenv.
> 
> Although I'm not sure if this is a good indicator for qemu.

Yeah, I saw that as well, and I don't believe that is a good indicator,
because BOCHS is probably from the x86 emulator project.

I did do some additional research after I sent the email, and HyperV uses
the FADT acpi table, and it does look like qemu has code to generate
the FADT table w/ QEMU as the hypervisor string, but for some reason the
HVF code isn't triggering the generation of the FADT table.  This seems
like a promising way to detect it.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."