On 08/07/2012 05:14 PM, Alexander Graf wrote: > > > On 07.08.2012, at 16:10, Avi Kivity <a...@redhat.com> wrote: > >> On 08/07/2012 05:08 PM, Alexander Graf wrote: >>> >>> >>> On 07.08.2012, at 15:58, Avi Kivity <a...@redhat.com> wrote: >>> >>>> On 08/07/2012 04:44 PM, Alexander Graf wrote: >>>>> >>>>>> >>>>>> Is this the correct place? Who says the caller of hva_to_pfn() is going >>>>>> to map it? >>>>> >>>>> I don't think anyone is. However, we need the struct page, and all the >>>>> generic kvm mm code tries hard to hide it from its users. The alternative >>>>> would be to expose all those details, and I'm not sure that's a good idea. >>>>> >>>>> Essentially, we don't care if we're overly cautious. Clearing one page >>>>> too much is way better than clearing one too few. >>>> >>>> Are you sure everyone uses hva_to_pfn()? x86 uses gfn_to_hva_many(), in >>>> one place. >>> >>> Nope, I only checked that e500 adheres to that flow so far. I'm not even >>> 100% sure that book3s is always happy yet. >>> >>> But I figured this is a step in the right direction. If we missed out on >>> one, we can always add it later. The many function is a good spot. Maybe >>> I'll just ckeck up all of kvm_main.c again for potential users. >> >> I'm not sure. We have lots of functions of this sort, and their number >> keeps increasing. Maybe a better place is pre-map. > > Pre-map? How?
In arch code before you install the page in a pte/tlbe. We don't have a single point we can hook unfortunately. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
