On 07.08.2012, at 16:20, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 08/07/2012 05:14 PM, Alexander Graf wrote: >> >> >> On 07.08.2012, at 16:10, Avi Kivity <avi@xxxxxxxxxx> wrote: >> >>> On 08/07/2012 05:08 PM, Alexander Graf wrote: >>>> >>>> >>>> On 07.08.2012, at 15:58, Avi Kivity <avi@xxxxxxxxxx> 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. So how do I get to the struct page in there? Alex > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
