From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 29 20:12:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03771065670 for ; Wed, 29 Sep 2010 20:12:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 794748FC13 for ; Wed, 29 Sep 2010 20:12:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o8TKCLwx060454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2010 23:12:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o8TKCLvo025918; Wed, 29 Sep 2010 23:12:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o8TKCLlc025917; Wed, 29 Sep 2010 23:12:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Sep 2010 23:12:21 +0300 From: Kostik Belousov To: Matthew Fleming Message-ID: <20100929201221.GG43070@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rPFbv4B2w2tcwGo5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Adding a V=R mapping for amd64? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 20:12:27 -0000 --rPFbv4B2w2tcwGo5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 29, 2010 at 12:40:57PM -0700, Matthew Fleming wrote: > I'm hacking around with making a "fast reboot" that puts a copy of the > MBR from disk into address 0x7c00 and, after disabling various > translation bits and stopping other CPUs, branches to it, to skip the > hardware self test that normally happens on boot. >=20 > I haven't gotten to the point of attempting to run the code at 0x7c00 > because I'm first hitting a different error. Despite my attempts to > enter a translation into the hardware page table, I get a panic trying > to write to address 0x7000, where I intended to put the trampoline > code that turns off translation. >=20 > Rebooting... > Attempt to reset to MBR... > XXX attempting pmap_kenter()... > XXX copying bootstrap code... > panic @ time 1285760103.939, thread 0xffffff000775d960: Fatal trap 12: > page fault while in kernel mode >=20 > cpuid =3D 0 > Panic occurred in module kernel loaded at 0xffffffff80100000: >=20 > Stack: -------------------------------------------------- > kernel:trap_fatal+0xac > kernel:trap_pfault+0x24c > kernel:trap+0x42e > kernel:bcopy+0x16 > kernel:shutdown_reset+0x48 > kernel:boot+0x317 > kernel:reboot+0x60 > kernel:ia32_syscall+0x1cd > -------------------------------------------------- > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x7000 > fault code =3D supervisor write data, page not present > stack pointer =3D 0x10:0xffffff8059e07670 > frame pointer =3D 0x10:0xffffff8059e07780 >=20 > Here's what I think is the relevant snippets of code. Note that I > reserved the vm_page_t for physical page 7 as mbr_page early in boot, > so I know the memory is free. >=20 > void > pmap_kenter_VR(vm_paddr_t pa) > { > pmap_t pmap =3D kernel_pmap; > vm_page_t mpte; > pd_entry_t *pde; > pt_entry_t *pte; >=20 > vm_page_lock_queues(); > PMAP_LOCK(pmap); > mpte =3D pmap_allocpte(pmap, pa, M_WAITOK); >=20 > pde =3D pmap_pde(pmap, pa); > if (pde =3D=3D NULL || (*pde & PG_V) =3D=3D 0) > panic("%s: invalid page directory va=3D%#lx", __func__, pa); > if ((*pde & PG_PS) !=3D 0) > panic("%s: attempted pmap_enter on 2MB page", __func__); > pte =3D pmap_pde_to_pte(pde, pa); > if (pte =3D=3D NULL) > panic("%s: no pte va=3D%#lx", __func__, pa); >=20 > if (*pte !=3D 0) { > /* Remove extra pte reference. */ > mpte->wire_count--; > } > pte_store(pte, pa | PG_RW | PG_V | PG_G | pg_nx); > =09 > vm_page_unlock_queues(); > PMAP_UNLOCK(pmap); > } >=20 > Then in cpu_reset(): >=20 > /* > * Establish a V=3DR mapping for the MBR page, and copy a > * reasonable guess at the size of the bootstrap code into the > * beginning of the page. > */ > printf("XXX attempting pmap_kenter()...\n"); > pmap_kenter_VR(trunc_page(mbaddr)); > printf("XXX copying bootstrap code...\n"); > to_copy =3D (uintptr_t)xxx_reset_end - (uintptr_t)xxx_reset_real; > if (to_copy > mbaddr - trunc_page(mbaddr)) > to_copy =3D mbaddr - trunc_page(mbaddr); > bcopy(xxx_reset_real, (void *)trunc_page(mbaddr), to_copy); /* die here= */ > printf("XXX attempting to turn off xlation and re-run MBR...\n"); > xxx_reset_real(mbaddr); >=20 >=20 > My first attempt was a call to > pmap_kenter(trunc_page(0x7c00), trunc_page(0x7c00)); > which failed trying to dereference the non-existent PDE. >=20 > My second attempt called > pmap_enter(kernel_pmap, trunc_page(0x7c00), VM_PROT_WRITE, mbr_page, > VM_PROT_ALL, 0); > That failed with the same crash as the attempt using pmap_kenter_VR(). >=20 > So... any thoughts as to why, after an apparently successful > installation of an xlation, I still get a panic as though there were > no xlation? Weird formatting of backtrace. Is this some proprietary code ? Why do you try to create 1-1 mapping at all ? The MBR code should be executing in real mode anyway, and the mapping address at the moment of bcopy does not matter at all. I think that the use of PHYS_TO_DMAP() should give you direct mapping. About the #pf that you see. I think that this is due to the fact that you are modifying kernel pmap, while the active one is the pmap of the user process which context issued reboot(). --rPFbv4B2w2tcwGo5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyjnaUACgkQC3+MBN1Mb4gTmQCcCEQFXgRtClu9NDwO6wA8KpoV 37sAoN5LaB1RquPFkER/F4KGmIza+GfE =YNMd -----END PGP SIGNATURE----- --rPFbv4B2w2tcwGo5--