On Wed, Aug 01, 2018 at 12:14:59PM -0400, Bryan Steele wrote: > On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote: > > On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote: > > > After installing the 014_amdlfence patch released yesterday for 6.3, my > > > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu > > > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137). > > > I suppose this would also happen on vmm(4) and bhyve, however I don't have > > > any such AMD hosts available for testing. > > > > Hi Elmer, > > > > This was tested in vmm(4), which does work, unfortunately there was not > > extensive testing by in other virtualization software. The MSR that is > > being set here is only mentioned in AMDs whitepaper and I had no reason > > to believe any special consideration was needed for guest VMs on AMD > > processors. > > > > > It occurs both using libvirt's "EPYC" CPU model and using > > > "host-passthrough" > > > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine. > > > > > > I guess not many people are running OpenBSD as a VM, and even less on AMD > > > hardware. But still, a syspatch leaving the system unable to boot is > > > probably not a good thing. :) > > > > > > > Even so, I would like to apologize. This situation is unfortunate, and > > I'll try to work with other developers to find the best way forward. > > But, I regret I am only but an amateur magician. > > > > -Bryan. > > Actually, it looks like this is at least partially a KVM/QEMU bug. In > the meantime I guess the solution would be to do as you suggested and > set a different CPU model for now until Linux distros include a fix for > this. > > https://lkml.org/lkml/2018/2/21/1202 > > Afterwards, on the OpenBSD side, it looks like one small change may be > required in addition.. > > -Bryan. > > Index: sys/arch/amd64/amd64/identcpu.c > =================================================================== > RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v > retrieving revision 1.95.2.2 > diff -u -p -u -r1.95.2.2 identcpu.c > --- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 -0000 1.95.2.2 > +++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -0000 > @@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci) > > msr = rdmsr(MSR_DE_CFG); > #define DE_CFG_SERIALIZE_LFENCE (1 << 1) > - msr |= DE_CFG_SERIALIZE_LFENCE; > - wrmsr(MSR_DE_CFG, msr); > + if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) { > + msr |= DE_CFG_SERIALIZE_LFENCE; > + wrmsr(MSR_DE_CFG, msr); > + } > } > } > >
As far as I can tell, nowhere does AMD claim this is a RO MSR. Thus, KVM might not be doing the right thing here by #GPing the guest on write. It is possible though, that it is described this way in some document I don't have access to. The diff you propose above is safe however, so if you want to make that change, ok mlarkin. I will test the diff on real hardware today. I stand by my belief that KVM is doing something in a nonstandard way here, but I'll check real hardware to make sure. -ml
