Date: Tue, 14 Feb 2023 01:48:10 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Ronald Klop <ronald-lists@klop.ws> Cc: freebsd-arm@FreeBSD.org Subject: Re: detecting qemu/HVF on Apple M1 silicon Message-ID: <20230214094810.GF95670@funkthat.com> In-Reply-To: <306917284.1.1676366642956@mailrelay> References: <20230214080530.GE95670@funkthat.com> <306917284.1.1676366642956@mailrelay>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230214094810.GF95670>