Muli Ben-Yehuda wrote: >>> >>> >> Why avoid rmap on mmio pages? Sure it's unnecessary work, but >> having less cases improves overall reliability. >> > > The rmap functions already have a check to bail out if the pte is not > an rmap pte, so in that sense, we aren't adding a new case for the > code to handle, just adding direct MMIO ptes to the existing list of > non-rmap ptes. > >
I'm worried about the huge chain of direct_mmio parameters passed to functions, impact on the audit code (at the end of mmu.c, and the poor souls who debug the mmu. >> You can use pfn_valid() in gfn_to_pfn() and kvm_release_pfn_*() to >> conditionally update the page refcounts. >> > > Since rmap isn't useful for direct MMIO ptes, doesn't it make more > sense to "bail out" early rather than in the bowls of the rmap code? > It does, from a purist point of view (which also favors explicit parameters a la direct_mmio rather than indirect parameters like pfn_valid()), but I'm looking from the practical point of view now. With mmu notifiers, we don't need to hold the refcount at all. So presuming we drop the refcounting code completely, are any changes actually necessary here? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
