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 07:32:35 +0300 Message-ID: <47F30C63.4080402@qumranet.com> References: <47F29057.7050004@qumranet.com> <47F2955B.6060200@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, andrea@qumranet.com, allen.m.kay@intel.com, Ben-Ami Yassour1 To: Anthony Liguori Return-path: In-Reply-To: <47F2955B.6060200@codemonkey.ws> 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 Anthony Liguori wrote: > What about switching the KVM MMU code to use hfn_t instead of struct > page? The initial conversion is pretty straight forward as the places > where you actually need a struct page you can always get it from > pfn_to_page() (like in kvm_release_page_dirty). > > We can then teach the MMU to deal with hfn_t's that don't have a > corresponding page. IIUC, the implementation of something like > kvm_release_page_dirty is a nop for pfn's that don't have a > corresponding page. We just have to be able to detect a pfn_to_page() > failure and then assume we're dealing with IO memory. > > It ought to work. gfn_to_hfn() (old gfn_to_page) will still need to take a refcount if possible. 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. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- 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