From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/1] direct mmio for passthrough - kernel part Date: Wed, 02 Apr 2008 12:50:50 +0300 Message-ID: <47F356FA.6010409@qumranet.com> References: <47F29057.7050004@qumranet.com> <47F2955B.6060200@codemonkey.ws> <47F30C63.4080402@qumranet.com> <20080402070306.GG19189@duo.random> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, allen.m.kay@intel.com, Ben-Ami Yassour1 To: Andrea Arcangeli Return-path: In-Reply-To: <20080402070306.GG19189@duo.random> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Andrea Arcangeli wrote: > On Wed, Apr 02, 2008 at 07:32:35AM +0300, Avi Kivity wrote: > >> It ought to work. gfn_to_hfn() (old gfn_to_page) will still need to take a >> refcount if possible. >> > > This reminds me, that mmu notifiers we could implement gfn_to_hfn only > with follow_page and skip the refcounting on the struct page. > > I'm not suggesting that though, the refcount makes the code more > robust IMHO, and notably it allows to run on kernels without mmu > notifiers. > > Isn't it faster though? We don't need to pull in the cacheline containing the struct page anymore. We could hack something to make pre mmu notifier kernels work. > > I'm unsure if it's good to add struct pages for non-ram, I find it > slightly confusing and not the right thing, it takes memory for stuff > that can't happen (refcounting only makes sense if the page finally > goes in the freelist when count reaches 0, and PG_dirty/referenced > bits and the like don't make sense either for non-ram or > reserved-ram). So I'm not sure the vmemmap trick is the best. > > I thought we'd meet with resistance to that idea :) though I'd like to point out that struct pages to exist for mmio on some machines (those with >= 4GB). >> This will increase the potential for type errors, so maybe we need to make >> gfn_t and hfn_t distinct structures, and use accessors to get the actual >> values. >> > > That's also a possibility. If we go for this then hfn_t is probably a > better name as it's less likely to collide with core kernel VM > code. Otherwise perhaps "pfn" can be used instead of hfn, it's up to > you ;). > I guess we can move to pfn, they're unambiguous enough. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace