Date: Mon, 27 Oct 2014 11:36:41 -0500 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, Warner Losh <imp@freebsd.org> Subject: Re: svn commit: r273214 - in head/sys: amd64/vmm/intel modules/vmm Message-ID: <2B7C3745-04E4-4FA9-A849-AECE54EA83A3@bsdimp.com> In-Reply-To: <1725598.2CCKLon8F3@ralph.baldwin.cx> References: <201410171320.s9HDKo53045297@svn.freebsd.org> <1725598.2CCKLon8F3@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_25BDB42C-D6E2-4B9A-BDC5-8C8727B4CD4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 27, 2014, at 10:54 AM, John Baldwin <jhb@freebsd.org> wrote: > 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 >>=20 >> Log: >> Fix build to not bogusly always rebuild vmm.ko. >>=20 >> 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. >>=20 >> With these items fixed, we no longer build vmm.ko every single time >> through the modules on a KERNFAST build. >=20 > So I cheered for this before, but it appears to be broken. :( >=20 > Namely, I rebuilt world + kernel on my laptop this weekend (it was = about a=20 > month old). My normal setup builds kernels with NO_KERNELCLEAN=3Dyes. = On my=20 > next reboot when I started a bhyve VM I promptly got a panic due to a = page=20 > fault in this assembly code: >=20 > /* > * 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 >=20 > (The 'cmpq' instruction) >=20 > This change came to mind, so I blew away the 'vmm' module directory = and=20 > rebuilt my kernel. Comparing the assembly of this instruction before = and=20 > after used different values for VMX_EPTGEN. In other words, the=20 > NO_KERNELCLEAN=3Dyes build failed to regenerate vmx_assym.h and the = build used=20 > stale values. Is there a way to force this condition for testing? > In particular, if you examine the generated .depend file, you will = find that=20 > there are no dependencies recorded for vmx_genassym.o, so it is never = rebuilt=20 > if any of the headers it includes are changed. In my case the panic = happened=20 > to be one that was easily diagnosed, but I could imagine stale assym = headers=20 > causing very odd crashes that would be quite hard to track down. I = think=20 > these changes should be reverted if we can't fix the dependencies of = the=20 > associated object files they are generated from. :( Give me a bit and I=92ll fix it. There=92s a number of implicit = dependencies that don=92t get recorded in the .depend file, iirc, so = that=92s not completely conclusive. Not building, though is kinda a big = hint that something=92s amiss. However, -DNO_CLEAN has always been a very-sharp edged tool that will = cut you in a number of ways, so there=92s no rush to back this out. Warner --Apple-Mail=_25BDB42C-D6E2-4B9A-BDC5-8C8727B4CD4C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUTnSZAAoJEGwc0Sh9sBEAtssP/ihxpIZuBrJF0yFr713jTxzQ KAaeFU+ERLT+Uc6KAHUXW4EQ6w59xfFy0ek5bQv+fkteH5RskzE8pPFdNPa2qPkS cgHQkx15eBlCJF1qwIsq9aSfRAUFBy3S0K2qzsI0KgXPr0PSKfepiMIzzyvvh/co GlrG0hBvQsPKwz4FgU+Gqi6rqb9KEvw2BULGcjU047YxEusgeBxpnmpiUeP19arS bR+G/H+gmtFD2vHfB765d4XtB2ktlyFZDKGoeMDwD4OuMzn7A9lGJVDE9SptMy8b N8LtgIli/I5BodZGAp2oNnEp760RQiHeNhxe5yfjbJqsE9OX0NTXT/ZFbQhyWtve sKvbd3hSpTKsX2aCVQ7VwVLp1pniOJx2w7nifh4zA8Fwvj/utUccA626sQ6As2+P cYsAvETq/qkSuDGnngRBMUJS1yq65xFcMJcjt0YslSFpHgbFwP5o9p4qTB9u3957 jSm2mGiTW+B/HIhq8FAZ4/HKDwvrhpnsK6l9/UK/fx1q7Lgv/ybdD/pkl0qdaYNo tYfQULFz3T9sb4UDpU8iGD+GmKsh3nXfTu1pl9GwChwaJne2mL13TuNdWRbV/jNz U8FcbGvcx93fOUBPdshJA/x3PGKqdljS1aBiDYZ2/Oa+mpyk8ZbeCFTAeHN++rZY 0LJvKU/+tiFkbj4qm4JB =/VLc -----END PGP SIGNATURE----- --Apple-Mail=_25BDB42C-D6E2-4B9A-BDC5-8C8727B4CD4C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2B7C3745-04E4-4FA9-A849-AECE54EA83A3>