>> So this needs to be cleared up given this is key to logging. >> Cases this code handles during migration - >> 1. huge page fault described above - write protect fault so you breakup >> the huge page. >> 2. All other faults - first time access, pte write protect you again wind up >> in >> stage2_set_pte(). >> >> Am I missing something here? >> > > no, I forgot about the fact that we can take the permission fault now. > Hmm, ok, so either we need to use the original approach of always > splitting up huge pages or we need to just follow the regular huge page > path here and just mark all 512 4K pages dirty in the log, or handle it > in stage2_set_pte(). > > I would say go with the most simple appraoch for now (which may be going > back to splitting all pmd_huge() into regular pte's), and we can take a > more careful look in the next patch iteration. >
Looking at the overall memslot update architecture and various fail scenarios - user_mem_abort() appears to be the most optimal and reliable place. First Write Protect huge pages after memslots are committed and deal with rest in user_mem_abort(). Still need some feedback on the pud_huge() before revising for next iteration? - Mario -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
