svn commit: r273214 - in head/sys: amd64/vmm/intel modules/vmm

[John Baldwin]

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