Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> [EMAIL PROTECTED] wrote: >>> >>>> From: Ben-Ami Yassour <[EMAIL PROTECTED]> >>>> >>>> Enable a guest to access a device's memory mapped I/O regions >>>> directly. >>>> Userspace sends the mmio regions that the guest can access. On the >>>> first >>>> page fault for an access to an mmio address the host translates the >>>> gva to hpa, >>>> and updates the sptes. >>>> >>>> >>> >>> 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? >>> >> >> /dev/mem is often restricted in what memory can be mapped. > > Please elaborate.
http://lkml.org/lkml/2008/1/30/473 Ubuntu now carries this and I think Fedora has carried something like this for a long time. It's okay for us because we just need device memory access but who knows if it will be restricted more in the future. If X ever gets their act together and gets proper kernel drivers, I think there would be a strong case for removing /dev/mem altogether. >> However, we can't add something like this to KVM that allows >> arbitrary HPA's to be mapped into a guest from userspace. This is >> just as bad as /dev/mem and is going to upset a lot of people. > > Device assignment is as rootish as you get. In an SELinux world, root may still have limited access to the system. In an ideal world, we would be able to guarantee that at worst, a guest can only harm the device it has access to and nothing else on the system. This probably requires MSI and VT-d. Even then, you may be able to physically damage the system by improperly programming the device. >> >> >> Regardless of whether we can use /dev/mem, I think we should >> introduce a new char device anyway. We only need to mmap() MMIO >> regions which are mapped by the PCI bus, presumably, the kernel >> should know about these mappings. The driver should only allow >> mappings that are valid for a particular PCI device such that it >> cannot be abused to map arbitrary regions of memory into a guest. >> Bonus points if it can validate that there isn't a valid Linux driver >> loaded for the given PCI device. > > This is a very good idea. > > The interface exposed would be the same as /dev/mem, so any kvm > modifications to get /dev/mem working would be applicable to > /dev/pci/*, no? I looked at Andrea's patches and I didn't see any special handling for non-RAM pages. Something Muli mentioned that kept them from doing /sys/devices/pci/.../region to begin with was the fact that IO pages do not have a struct page backing them so get_user_pages() will fail in gfn_to_page(). It's not too hard to modify the code to also try get_user_pages() to look up the VMA instead of the struct page. From the VMA, you can get the HPA for an IO mapping. The problem though is that gfn_to_page() wants to return a page, not a HPA. I haven't looked too deeply yet, but my suspicion is that to properly support mapping in VM_IO pages will require some general refactoring since we always assume that a struct page exists for any HPA. 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
