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? Alex > > > -- > 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
