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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
