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: Tue, 01 Apr 2008 22:43:19 +0300 Message-ID: <47F29057.7050004@qumranet.com> References: 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 To: Ben-Ami Yassour1 Return-path: In-Reply-To: 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 Ben-Ami Yassour1 wrote: >> >> Can you explain why you're not using the regular memory slot mechanism? >> i.e. have userspace mmap(/dev/mem) and create a memslot containing that >> at the appropriate guest physical address? >> >> > Our initial approach was to mmap /sys/bus/pci/devices/.../resource# > and create a memory slot for it. However eventually we realized that for > mmio we don't need hva mapped to the mmio region, we can map the gpa > directly to hpa. > > As far as I understand, the memory slots mechanism is used to map > gpa to hva. Then gfn_to_page uses get_user_pages to map hva to hpa. > However, get_user_pages does not work for mmio, and in addition we > know the hpa to begin with, so there is no real need to map an hva > for the mmio region. > > In addition there is an assumption in the code that there is a page > struct for the frame which is not the case for mmio. So it was > easier to simply add a list of mmio gpa-hpa mapping. > > I guess we can use the memory slots array to holds the gpa to hpa > mapping but it is not necessarily natural, and would probably > require more hooks in the code to handle an mmio memory slot. BTW, > note that for a guest that has multiple passthrough devices each > with a set of mmio regions, it might become a long list, so there > might be value to keep it separate from that respect as well. > > With regards to the potential security issue Anthony pointed out > (ioctls taking hpa's) we can change the interface so that they will > take (device, BAR) instead and the kernel will translate to hpa > > 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. -- 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