On Wed, Nov 17, 2021 at 02:09:50AM +0000, Klemens Nanni wrote:
> On Sat, Nov 13, 2021 at 09:36:21AM -0700, Theo de Raadt wrote:
> > Did the vm previously have a fdc? I doubt it. I am surprised fdcprobe()
> > returns a success.
>
> Turns out fdc(4) attaches only sometimes. Sometimes on cold VM boot,
> sometimes only upon warm reboot.
I've had consistent results with fdc(4) appearing in VMS on an X220. Bisecting
kernels identified this commit as the root cause:
0a894fa656a20dcd3351d61ee4e14415e615ef83 is the first bad commit
commit 0a894fa656a20dcd3351d61ee4e14415e615ef83
Author: dv <d...@openbsd.org>
Date: Tue Aug 31 17:40:59 2021 +0000
vmm(4): add ipi for vmclear, unlock kernel
On Intel VMX hosts, when a guest migrates cpus, VMCS state needs
to be flushed to physical memory before being reloaded on the new
cpu. This diff adds a new ipi to allow a guest resuming on a new
cpu to signal to the old that it needs to vmclear.
To better surface the potential race conditions, unlock the kernel
after handling the ioctl to vmm and simplify the run loops for both
vmx and svm. This requires a new vcpu lock.
Tested by some on tech@. "go for it" @mlarkin
sys/arch/amd64/amd64/cpu.c | 4 +-
sys/arch/amd64/amd64/ipifuncs.c | 13 +-
sys/arch/amd64/amd64/vmm.c | 550 +++++++++++++++++++-------------------
sys/arch/amd64/include/cpu.h | 6 +-
sys/arch/amd64/include/intrdefs.h | 5 +-
sys/arch/amd64/include/vmmvar.h | 18 +-
6 files changed, 310 insertions(+), 286 deletions(-)
