On Sat, Dec 4, 2021 at 4:32 AM Claus Assmann <ca+openbsd_m...@esmtp.org>
wrote:

> My vultr OpenBSD 6.8 instance crashed and when it tried to reboot it
> failed at:
>
> root on sd0a (...)
> WARNING: / was not properly unmounted
> kernel: privileged instruction fault trap, code=0
> mds_handler_skl_avx+0x33:  clflush __ALIGN_SIZE+0x500(%rid,%rax,8)
>
...

> I noticed at least one difference however:
> the crashing system shows
> Using Skylake AVX MDS workaround
> which might be something related to the function mentioned above?


They have your virtualization guest configured in a way that doesn't match
any real hardware: it has a family-model-stepping combination that matches
the Skylake line, real hardware of which all have the cflushopt extension,
but the host is making the guest trap when that instruction is used.

You could test this theory by changing "clflushopt" to "clflush" in mds.S
and building a new ISO, but poking them to provide a more consistent
virtualization setup, whether by migration or reconfiguration, is the
better solution.

We could add more tests of the cpuid data and codepatch out the
instructions that should be there but aren't, but for something like the
clflushopt instruction where there's no real good reason for not passing
through the extension when the CPU presumably has it, it's hard to get much
enthusiasm up for working around a pointlessly dumb (or buggy)
virtualization config.



> Is this workaround something that could be turned off to see whether
> it causes the problem?
> The weird thing is that OpenBSD 6.8 was installed fine
> (11 months ago), so I don't understand why this problem happens now
> (could vultr have changed something in the underlying system?)
>

The machine hosting your guest probably suffered some failure (thus the
crash that you experienced) and they migrated your guest to another host to
get you back up and running.  I periodically see the tickets go by at my
$DAYJOB of this sort of replacement.  Hardware, especially modern PCs,
don't live anywhere near forever...


Philip Guenther

Reply via email to