Date: Mon, 27 Oct 2014 11:54:47 -0400 From: John Baldwin <jhb@freebsd.org> To: Warner Losh <imp@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r273214 - in head/sys: amd64/vmm/intel modules/vmm Message-ID: <1725598.2CCKLon8F3@ralph.baldwin.cx> In-Reply-To: <201410171320.s9HDKo53045297@svn.freebsd.org> References: <201410171320.s9HDKo53045297@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, October 17, 2014 01:20:50 PM Warner Losh wrote: > Author: imp > Date: Fri Oct 17 13:20:49 2014 > New Revision: 273214 > URL: https://svnweb.freebsd.org/changeset/base/273214 > > Log: > Fix build to not bogusly always rebuild vmm.ko. > > Rename vmx_assym.s to vmx_assym.h to reflect that file's actual use > and update vmx_support.S's include to match. Add vmx_assym.h to the > SRCS to that it gets properly added to the dependency list. Add > vmx_support.S to SRCS as well, so it gets built and needs fewer > special-case goo. Remove now-redundant special-case goo. Finally, > vmx_genassym.o doesn't need to depend on a hand expanded ${_ILINKS} > explicitly, that's all taken care of by beforedepend. > > With these items fixed, we no longer build vmm.ko every single time > through the modules on a KERNFAST build. So I cheered for this before, but it appears to be broken. :( Namely, I rebuilt world + kernel on my laptop this weekend (it was about a month old). My normal setup builds kernels with NO_KERNELCLEAN=yes. On my next reboot when I started a bhyve VM I promptly got a panic due to a page fault in this assembly code: /* * If 'vmx->eptgen[curcpu]' is not identical to 'pmap->pm_eptgen' * then we must invalidate all mappings associated with this EPTP. */ movq PM_EPTGEN(%r11), %r10 cmpq %r10, VMX_EPTGEN(%rsi, %rax, 8) je guest_restore (The 'cmpq' instruction) This change came to mind, so I blew away the 'vmm' module directory and rebuilt my kernel. Comparing the assembly of this instruction before and after used different values for VMX_EPTGEN. In other words, the NO_KERNELCLEAN=yes build failed to regenerate vmx_assym.h and the build used stale values. In particular, if you examine the generated .depend file, you will find that there are no dependencies recorded for vmx_genassym.o, so it is never rebuilt if any of the headers it includes are changed. In my case the panic happened to be one that was easily diagnosed, but I could imagine stale assym headers causing very odd crashes that would be quite hard to track down. I think these changes should be reverted if we can't fix the dependencies of the associated object files they are generated from. :( -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1725598.2CCKLon8F3>