Manawyrm wrote:
> (Hetzner engineer here, but speaking as a private individual)
>
> Hetzner Cloud is using regular mainline QEMU on Linux as the hypervisor,
> so while I'd agree that faulting when the MSR is set isn't ideal, this
> behaviour will probably also occur on a lot of other machines/se
Hi,
(Hetzner engineer here, but speaking as a private individual)
Hetzner Cloud is using regular mainline QEMU on Linux as the hypervisor,
so while I'd agree that faulting when the MSR is set isn't ideal, this
behaviour will probably also occur on a lot of other machines/setups.
Another solut
I hit the same trap as Lucas with my HV (netcup.de).
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5900 (10 entries)
bios0: vendor netcup version "RS 1000 G9 Plus" date 12/17/2020
bios0: netcup KVM Server
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices
Would like to know if this patch helps anyone with this type of
problem.
Index: sys/arch/amd64/amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.172
diff -u -p -u -r1.172 cpu.c
--- sys/arch/amd64/am
I am not aware of a feature flag we can check for if we can
write to MSR_DE_CFG, and my guess is their VM needs to silently
ignore the bits we modify, and not generate a fault.
I'm not sure what we can do here, but I suspect some developers will
think about it.
Anyways, they decided to fault. T
Hey,
I'm running this on a Hetzner VPS, with the dmesg below. I ran syspatch
followed by installboot -v sd0. After each boot, 100% I get
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC Processor, 2445.60 MHz, 17-31-00
cpu0: FPU,... (proc capabilities)
cpu0: 32KB ... (cache info)
cpu0: sm
Zenbleed errata for 7.2 and 7.3 will come out soon.
sysupgrade of the -current snapshot already contains a fix.
I wanted to share some notes on impact:
OpenBSD does not use the AVX instructions to the same extent that Linux
and Microsoft do, so this is not as important.
On Linux, glibc has AVX
