Andrea Arcangeli wrote: > On Tue, Apr 01, 2008 at 10:20:49AM -0500, Anthony Liguori wrote: > >> Which is apparently entirely unnecessary as we already have >> /sys/bus/pci/.../region. It's just a matter of checking if a vma is VM_IO >> and then dealing with the subsequent reference counting issues as Avi >> points out. >> > > Do you need to map it in userland too, isn't it enough to map it in > the sptes? > > For the ram I had to map it in userland too with /dev/mem, and then I > used the pte_pfn to fill the spte, so the emulated qemu drivers can > input/output. But for the mmio space I doubt the userland side is > needed. > > If you add a direct memslot (new bitflag type) I will use it too > instead of catching get_user_pages failures and walking ptes on the > RAM pieces overwritten by /dev/mem. >
There's a certain amount of elegance in mapping to userspace and not introducing a direct memslot. It helps simplify the security model since an application isn't able to do anything more than it could without KVM. The difficulty with a direct memslot is how you introduce policies to limit what guests can access what memslots directly. You would have to teach KVM to interact with the PCI subsystem to determine what memory was within a particular PCI IO region. Not impossible, just ugly. 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
