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