From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: KVM: MMU: drop read-only large sptes when creating lower level sptes Date: Tue, 25 Feb 2014 23:11:19 +0800 Message-ID: <1D2584DA-BA76-4065-9153-9B765F16AF29@linux.vnet.ibm.com> References: <20140224165932.GA15971@amt.cnet> <530C0E5D.4030308@linux.vnet.ibm.com> <20140225131321.GA2939@amt.cnet> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm-devel , Paolo Bonzini To: Marcelo Tosatti Return-path: Received: from mail-pd0-f174.google.com ([209.85.192.174]:38412 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753221AbaBYPLb convert rfc822-to-8bit (ORCPT ); Tue, 25 Feb 2014 10:11:31 -0500 Received: by mail-pd0-f174.google.com with SMTP id y13so3056301pdi.19 for ; Tue, 25 Feb 2014 07:11:30 -0800 (PST) In-Reply-To: <20140225131321.GA2939@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Feb 25, 2014, at 9:13 PM, Marcelo Tosatti wrot= e: > On Tue, Feb 25, 2014 at 11:30:37AM +0800, Xiao Guangrong wrote: >> On 02/25/2014 12:59 AM, Marcelo Tosatti wrote: >>>=20 >>> Read-only large sptes can be created due to read-only faults as >>> follows: >>>=20 >>> - QEMU pagetable entry that maps guest memory is read-only=20 >>> 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-onl= y. >>> - Write-fault on such memory causes guest to loop endlessly >>> (which must go down to level 1 because dirty logging is enabled). >>=20 >> Hi Marcelo, >>=20 >> 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? >=20 > You mean COW was not broken by gup? (that is the problem, so a > read-only large spte is created). >=20 I mean the final step that =93Write-fault on such memory causes guest=94= should break the readonly QEMU pagetable entry and change it to writable, at t= hat time, mmu-notifier should be called since the page=92s permission has b= een changed. After read the code more carefully, i figure the reason out that mmu-no= tifier 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 he= re. - if we do proper prefetch when it happen, the addition page-fault can be avoided, that is good for the performance.