From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 1/1] direct mmio for passthrough - kernel part Date: Tue, 01 Apr 2008 15:04:43 -0500 Message-ID: <47F2955B.6060200@codemonkey.ws> References: <47F29057.7050004@qumranet.com> 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, andrea@qumranet.com, Ben-Ami Yassour1 To: Avi Kivity Return-path: In-Reply-To: <47F29057.7050004@qumranet.com> 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 Avi Kivity wrote: > Ben-Ami Yassour1 wrote: > >> >> > > Not enough. How do you know if this calling process has permissions to > access that pci device (I retract my previous "pci passthrough is as > rootish as you get" remark). > > >> What do you think? Given that the shadow page table code has to be >> modified anyway (due to the struct page issue), is it worthwhile to >> experiment with mmap(...region) or is the current approach sufficient? >> >> > > As Anthony points out, the advantage to mmap() is that whatever security > is needed can be applied at that level. Passing host physical addresses > from userspace requires a whole new security model. > > The issue with gfn_to_page() is real. We can either try to work around > it somehow, or we can try to back mmio regions with struct pages. Now > that it looks like mem_map is becoming virtually mapped, the cost is > minimal, but I expect this approach will meet some resistance. > 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. Regards, Anthony Liguori ------------------------------------------------------------------------- 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