From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 6 03:51:05 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 3DDC810656C1 for ; Mon, 6 Sep 2010 03:51:05 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFDFF8FC15 for ; Mon, 6 Sep 2010 03:51:04 +0000 (UTC) Received: by yxn35 with SMTP id 35so1634505yxn.13 for ; Sun, 05 Sep 2010 20:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=4AATZQjvsrm00l9IY48K/ixNoK+v2nBNYACNmyTdQtY=; b=UTUIqTQgOFpCcYUgw6d6OXMJot8x3RSTu6sLenJFlnRSwYXCbAYrpb4OKCmphstNpI C9S88kLFM9Wkd166RE5sBo9K+s5tWZJ51TJV1BbsjtylEQ+CRcm+1AeELgzXMJvRRIe+ Fp4xHtEKwp2ZEXBgFqLmIot31yftOQtEMsi1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wWIZwcnCiAScAR06NKAmdz6BpzfC8sPpKbVNae2LelfzFMRqs3rJ4oLWgkV2Hoqk1b SIZrHfMIKz0db5bkYhORgnTKfnUpdpRuv1FgxFEo8qpYiUR/AXjMv2FibYLGa05i/PiO x5vdDfSWO5Msp2ck646eQ484+PjfJiJOOmSso= MIME-Version: 1.0 Received: by 10.100.164.4 with SMTP id m4mr2490235ane.135.1283745063605; Sun, 05 Sep 2010 20:51:03 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Sun, 5 Sep 2010 20:51:03 -0700 (PDT) In-Reply-To: <4C844609.9050505@freebsd.org> References: <4C844609.9050505@freebsd.org> Date: Mon, 6 Sep 2010 03:51:03 +0000 X-Google-Sender-Auth: POTI0Ml5ooT63vXo2uN3yuMMKfE Message-ID: From: mdf@FreeBSD.org To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: UMA allocations from a specific physical range 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: Mon, 06 Sep 2010 03:51:05 -0000 On Mon, Sep 6, 2010 at 1:38 AM, Nathan Whitehorn wrote: > PowerPC hypervisors typically provided a restricted range on memory when > the MMU is disabled, as it is when initially handling exceptions. In > order to restore virtual memory, the powerpc64 code needs to read a data > structure called the SLB cache, which is currently allocated out of a > UMA zone, and must be mapped into wired memory, ideally 1:1 > physical->virtual address. Since this must be accessible in real mode, > it must have a physical address in a certain range. I am trying to > figure out the best way to do this. > > My first run at this code uses a custom UMA allocator that calls > vm_phys_alloc_contig() to get a memory page. The trouble I have run into > is that I cannot figure out a way to free the page. Marking the zone > NOFREE is a bad solution, vm_page_free() panics the kernel due to > inconsistent tracking of page wiring, and vm_phys_free_pages() causes > panics in vm_page_alloc() later on ("page is not free"). What is the > correct way to deallocate these pages? Or is there a different approach > I should adopt? I assume this is for the SLB flih? What AIX did was to have a 1-1 simple esid to vsid translation for kernel addresses, reserve the first 16 SLB entries for various uses, including one for the current process's process private segment, and if the slb miss was on a process address we'd turn on translation and look up the answer, the tables holding the answer being in the process private segment effective address space so we wouldn't take another slb miss. This required one level deep recursion in the slb slih, in case there was a miss on kernel data with xlate on in the SLB slih. For historical reasons due to the per-process segment table for POWER3, we also had a one-page hashed lookup table per process that we stored the real address of in the process private segment, so the assembly code in the flih looked here before turning on MSR_DR IIRC. I was trying to find ways to kill this code when I left IBM, since we'd ended support for POWER3 a few years earlier. I haven't had the time to look at FreeBSD ppc64 sources; how large are the uma-allocated slb entries and what is stored in them? The struct and filename is sufficient, though I don't have convenient access to sources until Tuesday. V=R space is rather limited (well, depending on a lot of factors; for AIX on Power5 and later the hypervisor only gave us 128M, though for ppc64 on a Mac G4 I assume all of memory can be mapped V=R if desired) so it was best to find a non V=R solution if possible. Turning on translation in the flih after some setup and recursion stopping is one of the easier ways, and also has the advantage of not needing to either have separate code or macro access to data structures used in both V and R modes. Cheers, matthew