From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH v2 12/15] KVM: MMU: allow locklessly access shadow page table out of vcpu thread Date: Tue, 8 Oct 2013 12:02:32 +0800 Message-ID: References: <1378376958-27252-1-git-send-email-xiaoguangrong@linux.vnet.ibm.com> <1378376958-27252-13-git-send-email-xiaoguangrong@linux.vnet.ibm.com> <20131008012355.GA3588@amt.cnet> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Xiao Guangrong , gleb@redhat.com, avi.kivity@gmail.com, pbonzini@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: In-Reply-To: <20131008012355.GA3588@amt.cnet> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Hi Marcelo, On Oct 8, 2013, at 9:23 AM, Marcelo Tosatti wrote= : >>=20 >> + if (kvm->arch.rcu_free_shadow_page) { >> + kvm_mmu_isolate_pages(invalid_list); >> + sp =3D list_first_entry(invalid_list, struct kvm_mmu_page, link); >> + list_del_init(invalid_list); >> + call_rcu(&sp->rcu, free_pages_rcu); >> + return; >> + } >=20 > This is unbounded (there was a similar problem with early fast page f= ault > implementations): >=20 > From RCU/checklist.txt: >=20 > " An especially important property of the synchronize_rcu() > primitive is that it automatically self-limits: if grace perio= ds > are delayed for whatever reason, then the synchronize_rcu() > primitive will correspondingly delay updates. In contrast, > code using call_rcu() should explicitly limit update rate in > cases where grace periods are delayed, as failing to do so can > result in excessive realtime latencies or even OOM conditions. > " I understand what you are worrying about=85 Hmm, can it be avoided by just using kvm->arch.rcu_free_shadow_page in a small window? - Then there are slight chance that the page need to be freed by call_rcu. >=20 > Moreover, freeing pages differently depending on some state should=20 > be avoided. >=20 > Alternatives: >=20 > - Disable interrupts at write protect sites. The write-protection can be triggered by KVM ioctl that is not in the V= CPU context, if we do this, we also need to send IPI to the KVM thread when= do TLB flush. And we can not do much work while interrupt is disabled due = to interrupt latency. > - Rate limit the number of pages freed via call_rcu > per grace period. Seems complex. :( > - Some better alternative. Gleb has a idea that uses RCU_DESTORY to protect the shadow page table and encodes the page-level into the spte (since we need to check if the= spte is the last-spte. ). How about this? I planned to do it after this patchset merged, if you like it and if yo= u think that "using kvm->arch.rcu_free_shadow_page in a small window" can not a= void the issue, i am happy to do it in the next version. :) Thanks, Marcelo!