From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: KVM: MMU: drop read-only large sptes when creating lower level sptes Date: Tue, 25 Feb 2014 19:52:49 -0300 Message-ID: <20140225225249.GA16552@amt.cnet> References: <20140224165932.GA15971@amt.cnet> <530C0E5D.4030308@linux.vnet.ibm.com> <20140225131321.GA2939@amt.cnet> <1D2584DA-BA76-4065-9153-9B765F16AF29@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm-devel , Paolo Bonzini To: Xiao Guangrong Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31283 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751741AbaBYWxI (ORCPT ); Tue, 25 Feb 2014 17:53:08 -0500 Content-Disposition: inline In-Reply-To: <1D2584DA-BA76-4065-9153-9B765F16AF29@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Feb 25, 2014 at 11:11:19PM +0800, Xiao Guangrong wrote: >=20 > On Feb 25, 2014, at 9:13 PM, Marcelo Tosatti wr= ote: >=20 > > 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-o= nly. > >>> - 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 >=20 > I mean the final step that =E2=80=9CWrite-fault on such memory causes= guest=E2=80=9D should > break the readonly QEMU pagetable entry and change it to writable, at= that > time, mmu-notifier should be called since the page=E2=80=99s permissi= on has been > changed. >=20 > After read the code more carefully, i figure the reason out that mmu-= notifier > is not called when the page can be reused.=20 Well a transition from read-only host-pte to read-write host-pte does not require the read-only spte to be upgraded immediatelly, right? Permission is upgraded lazily. > I am thinking whether it is > reasonable: > - anyway, the permission bits on the pre are changed, why not call > mmu-notifier->change_pte()? It could, but lazy updates are better i suppose. > - kvm and other users of mum-notifier need to check the permission > changing very carefully, that is really subtle, like the case fixed = here. Yes. > - if we do proper prefetch when it happen, the addition page-fault ca= n > be avoided, that is good for the performance. Agree.=20