From owner-svn-src-projects@FreeBSD.ORG Wed Dec 19 12:11:01 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43AECDCA; Wed, 19 Dec 2012 12:11:01 +0000 (UTC) (envelope-from cherry@zyx.in) Received: from quietly-confident.xenoserver.net (quietly-confident.xenoserver.net [85.88.27.202]) by mx1.freebsd.org (Postfix) with ESMTP id BACDB8FC12; Wed, 19 Dec 2012 12:11:00 +0000 (UTC) Received: from foobar (unknown [117.199.5.171]) by quietly-confident.xenoserver.net (Postfix) with ESMTPSA id F3C052989; Wed, 19 Dec 2012 12:10:53 +0000 (UTC) From: Cherry G. Mathew To: src-committers@freebsd.org Subject: Re: svn commit: r244425 - projects/amd64_xen_pv/sys/amd64/xen References: <201212191209.qBJC93T4089069@svn.freebsd.org> Date: Wed, 19 Dec 2012 17:40:01 +0530 In-Reply-To: <201212191209.qBJC93T4089069@svn.freebsd.org> (Cherry G. Mathew's message of "Wed, 19 Dec 2012 12:09:03 +0000 (UTC)") Message-ID: <878v8uckfa.fsf@zyx.in> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: svn-src-projects@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 12:11:01 -0000 Apologies for deviating from the checkin log template. Approved by: gibbs(implicit) >>>>> "Cherry" == Cherry G Mathew writes: Cherry> Author: cherry Date: Wed Dec 19 12:09:02 2012 New Revision: Cherry> 244425 URL: http://svnweb.freebsd.org/changeset/base/244425 Cherry> Log: - Add a dummy userland pagetable pointer to keep xen Cherry> happy. This allows us to hypervisor_iret() into xen to Cherry> resume from exceptions. (Xen checks for a valid userland Cherry> pagetable irrespective of the domain "mode" (ie; Cherry> user/kernel)) being returned to. - Enhance xen_vm_vtop() to Cherry> lookup early (boottime) kernel mappings. - A few more Cherry> sanity checks ie; KASSERTS() Cherry> Modified: projects/amd64_xen_pv/sys/amd64/xen/pmap.c Cherry> Modified: projects/amd64_xen_pv/sys/amd64/xen/pmap.c Cherry> ============================================================================== Cherry> --- projects/amd64_xen_pv/sys/amd64/xen/pmap.c Wed Dec 19 Cherry> 12:00:09 2012 (r244424) +++ Cherry> projects/amd64_xen_pv/sys/amd64/xen/pmap.c Wed Dec 19 Cherry> 12:09:02 2012 (r244425) @@ -429,7 +429,7 @@ Cherry> pmap_xen_bootpages(vm_paddr_t *firstaddr uintptr_t va; Cherry> vm_paddr_t ma; Cherry> - /* Share info */ + /* i) Share info */ ma = Cherry> xen_start_info->shared_info; Cherry> /* This is a bit of a hack right now - we waste a Cherry> physical @@ -452,6 +452,27 @@ pmap_xen_bootpages(vm_paddr_t Cherry> *firstaddr PT_SET_MA(va, ma | PG_RW | PG_V | PG_U); Cherry> HYPERVISOR_shared_info = (void *) va; + + + /* ii) Cherry> Userland page table base */ + va = vallocpages(firstaddr, Cherry> 1); + bzero((void *)va, PAGE_SIZE); + + /* + * x86_64 has 2 Cherry> privilege rings and Xen keeps separate pml4 + * pointers for Cherry> each, which are sanity checked on every + * exit via Cherry> hypervisor_iret. We therefore set up a zeroed out + * user Cherry> page table pml4 to satisfy/fool xen. + */ + + /* Mark the Cherry> page r/o before pinning */ + pmap_xen_setpages_ro(va, 1); + Cherry> + /* Pin the table */ + xen_pgdir_pin(phystomach(VTOP(va))); Cherry> + + /* Register user page table with Xen */ + Cherry> xen_pt_user_switch(VTOP(va)); Cherry> } Cherry> /* Boot time ptov - xen guarantees bootpages to be offset Cherry> */ @@ -906,7 +927,12 @@ pmap_extract_and_hold(pmap_t pmap, Cherry> vm_of vm_paddr_t pmap_kextract(vm_offset_t va) { - return Cherry> xpmap_mtop(pmap_kextract_ma(va)); + vm_paddr_t ma; + ma = Cherry> pmap_kextract_ma(va); + + KASSERT(ma != 0, ("%s: Unmapped Cherry> va: 0x%lx \n", __func__, va)); + + return xpmap_mtop(ma); Cherry> } Cherry> vm_paddr_t @@ -1301,8 +1327,12 @@ xen_vm_vtop(uintptr_t va) Cherry> { int result; Cherry> - /* The kernel expects to have full access to its address Cherry> space */ - const vm_prot_t accesstype = VM_PROT_READ | Cherry> VM_PROT_WRITE | VM_PROT_EXECUTE; + /* + * The kernel expects Cherry> to have at least read access to its + * address space. On Cherry> Xen we don't have full access, since + * page-table pages, Cherry> for eg: are read-only. + */ + const vm_prot_t accesstype = Cherry> VM_PROT_READ; Cherry> vm_page_t m; vm_object_t object; /* Backing object for Cherry> this va */ @@ -1315,12 +1345,20 @@ xen_vm_vtop(uintptr_t va) Cherry> va <= VM_MAX_KERNEL_ADDRESS), ("Invalid kernel virtual Cherry> address")); Cherry> + if (va >= KERNBASE && va <= virtual_avail) { /* + * Boot Cherry> time page + */ + return VTOP(va); + } + /* Get the specific Cherry> object and pindex where the va may be mapped */ result = Cherry> vm_map_lookup(&kernel_map, va, accesstype, &entry, &object, Cherry> &pindex, &tmp_prot, &wired); Cherry> - KASSERT(result == KERN_SUCCESS, ("Couldn't find va in the Cherry> kernel map. \n")); - KASSERT(accesstype == tmp_prot, Cherry> ("Kernel access permissions disparity\n")); + KASSERT(result Cherry> == KERN_SUCCESS, ("Couldn't find va = 0x%lx in the kernel Cherry> map. \n", va)); + + KASSERT(accesstype | tmp_prot, ("Kernel Cherry> access permissions disparity for va = 0x%lx: %s\n", va, Cherry> ((tmp_prot & VM_PROT_READ) ? "VM_PROT_READ" : ( + (tmp_prot Cherry> & VM_PROT_WRITE) ? "| VM_PROT_WRITE" : ((tmp_prot & Cherry> VM_PROT_EXECUTE) ? "| VM_PROT_EXECUTE" : ""))))); Cherry> VM_OBJECT_LOCK(object); -- Cherry