Avi Kivity wrote: > Kay, Allen M wrote: > >> Still todo: move vt.d to kvm-intel.ko module. >> >> > > Not sure it's the right thing to do. If we get the iommus abstracted > properly, we can rename vtd.c to dma.c and move it to virt/kvm/. > > The code is certainly a lot more about managing memory than anything vmx > specific. It's hardly x86 specific, even. >
Really, an external interface to KVM that allowed someone to query the GPA => PA mapping would suffice. It should not fault in pages that aren't present and we should provide notifications for when the mapping changes for a given reason. Userspace can enforce the requirement that memory remains present via mlock(). This allows us to implement a PV API for DMA registration without the IOMMU code having any particular knowledge of it. Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
