From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 02:46:50 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 872BA16A412 for ; Tue, 2 Jan 2007 02:46:50 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.freebsd.org (Postfix) with SMTP id E09FB13C441 for ; Tue, 2 Jan 2007 02:46:49 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 2 Jan 2007 00:46:39 +0000 (GMT) To: Matthew Dillon In-Reply-To: Your message of "Sun, 31 Dec 2006 12:43:44 PST." <200612312043.kBVKhi7t095666@apollo.backplane.com> Date: Tue, 02 Jan 2007 00:46:38 +0000 From: Ian Dowse Message-ID: <200701020046.aa80712@nowhere.iedowse.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Confusion in acpi_sleep_machdep(). 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: Tue, 02 Jan 2007 02:46:50 -0000 In message <200612312043.kBVKhi7t095666@apollo.backplane.com>, Matthew Dillon w rites: > I'm trying to figure out how the acpi_sleep_machdep() code works and > there are a couple of lines I just don't understand: > > pm = vmspace_pmap(p->p_vmspace); > cr3 = rcr3(); >#ifdef PAE > load_cr3(vtophys(pm->pm_pdpt)); >#else > load_cr3(vtophys(pm->pm_pdir)); >#endif > > page = PHYS_TO_VM_PAGE(sc->acpi_wakephys); > pmap_enter(pm, sc->acpi_wakephys, page, > VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE, 1); > > First, why isn't it just using kernel_pmap ? What's all the load_cr3() > stuff for ? > > Second, why is it entering the physical address sc->acpi_wakephys > as the virtual address in the pmap ? Shouldn't it be using > sc->acpi_wakeaddr there? > > Anybody know ? I don't know the details, but acpi_sleep_machdep() sets up an identity mapping in the current process's vmspace (hence using virtual = physical). Lazy switching of address spaces means that cr3 may not currently refer to the same vmspace, which would break the identity mapping, so that's the reason for the load_cr3() calls. See revision 1.22 for a bit more information. Ian