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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
