On Feb 25, 2014, at 9:13 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > On Tue, Feb 25, 2014 at 11:30:37AM +0800, Xiao Guangrong wrote: >> On 02/25/2014 12:59 AM, Marcelo Tosatti wrote: >>> >>> Read-only large sptes can be created due to read-only faults as >>> follows: >>> >>> - QEMU pagetable entry that maps guest memory is read-only >>> due to COW. >>> - Guest read faults such memory, COW is not broken, because >>> it is a read-only fault. >>> - Enable dirty logging, large spte not nuked because it is read-only. >>> - Write-fault on such memory causes guest to loop endlessly >>> (which must go down to level 1 because dirty logging is enabled). >> >> Hi Marcelo, >> >> It surprised me that the large-readonly mapping was not dropped >> by mmu-notifer as this is write fault on readonly mapping in Qemu. >> Hmm... i missed something? > > You mean COW was not broken by gup? (that is the problem, so a > read-only large spte is created). > I mean the final step that “Write-fault on such memory causes guest” should break the readonly QEMU pagetable entry and change it to writable, at that time, mmu-notifier should be called since the page’s permission has been changed. After read the code more carefully, i figure the reason out that mmu-notifier is not called when the page can be reused. I am thinking whether it is reasonable: - anyway, the permission bits on the pre are changed, why not call mmu-notifier->change_pte()? - kvm and other users of mum-notifier need to check the permission changing very carefully, that is really subtle, like the case fixed here. - if we do proper prefetch when it happen, the addition page-fault can be avoided, that is good for the performance. -- 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
