Re: port-arm/60655: vmt(4) probes the VMware backdoor unconditionally on aarch64 and panics the kernel on hypervisors that do not implement it

On 06/09/2026 19:53, zakinko%snowrabbit.org@localhost wrote:

Thanks for catching that -- I had missed it.  I read the pointer as:
HypervisorId only exists from FADT revision 6, so the revision (and the
length) should be checked before the field is read.  Is that the right
understanding?

Two things I went on to do.  I am not confident about either, so I would
be grateful for your view:

- The FADT reading moved into a small helper in dev/acpi,
  acpi_fadt_hypervisor_id(), so that the next user of the field need not
  copy it.

Not a big fan of this helper, but OK, I guess.

- vmt_match() now probes only when the firmware names VMware, rather
  than skipping only when it names something else.

Sounds good.

  The difference shows
  on a hypervisor that traps MDCCSR_EL0 but leaves the field zero: the
  earlier form still panics there (I checked with a QEMU 11.1.0 patched
  to write zeros).

Any hypervisor that doesn’t provide a RAZ MDCCSR_EL0 is broken.

  The ACPI 6.0 note for the field reads to me as
  "probe only on a vendor you recognise", but I may be reading too much
  into it -- if you would rather keep the old behaviour on a zero field,
  it is a single condition to flip.

I think the code in the message is fine.

 
+#if NACPICA > 0
+	/*
+                                                                    ...  A
+	 * hypervisor other than VMware is free to answer that read with an
+	 * undefined instruction trap, which is fatal in kernel mode; QEMU
+	 * does so once the Apple vGIC is in use.

This is wrong.

QEMU was broken - it is now hopefully fixed with your diff.