From mboxrd@z Thu Jan  1 00:00:00 1970
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC] KVM: MMU: Don't use RCU for lockless shadow walking
Date: Tue, 24 Apr 2012 17:54:56 +0800
Message-ID: <4F967870.6080806@linux.vnet.ibm.com>
References: <1335197812-32064-1-git-send-email-avi@redhat.com> <4F964A2C.7050106@linux.vnet.ibm.com> <4F96703F.4000607@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm@vger.kernel.org
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e23smtp06.au.ibm.com ([202.81.31.148]:36078 "EHLO
	e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756600Ab2DXJzE (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 24 Apr 2012 05:55:04 -0400
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <xiaoguangrong@linux.vnet.ibm.com>;
	Tue, 24 Apr 2012 09:49:56 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3O9mFpo2285766
	for <kvm@vger.kernel.org>; Tue, 24 Apr 2012 19:48:15 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3O9swmB020198
	for <kvm@vger.kernel.org>; Tue, 24 Apr 2012 19:54:58 +1000
In-Reply-To: <4F96703F.4000607@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 04/24/2012 05:19 PM, Avi Kivity wrote:


>>> Turned out to be simpler than expected.  However, I think there's a problem
>>> with make_all_cpus_request() possible reading an incorrect vcpu->cpu.
>>
>>
>> It seems possible.
>>
>> Can we fix it by reading vcpu->cpu when the vcpu is in GUEST_MODE or
>> EXITING_GUEST_MODE (IIRC, in these modes, interrupt is disabled)?
>>
>> Like:
>>
>> if (kvm_vcpu_exiting_guest_mode(vcpu) != OUTSIDE_GUEST_MODE)
>>                       cpumask_set_cpu(vcpu->cpu, cpus);
> 
> I think it is actually okay.  We are only vulnerable if lockless shadow
> walk started during prepare_zap_page(), and extends past
> kvm_flush_remote_tlbs(), yes?  But in that case, vcpu->cpu is stable
> since local_irq_disable() kills preemption.
> 


This case can happen?

   VCPU 0                                           VCPU 1

kvm_for_each_vcpu(i, vcpu, kvm) {
	kvm_make_request(req, vcpu);

                                                  VCPU1 is running on CPU 1 out of guest mode

	cpu = vcpu->cpu;

	/* Set ->requests bit before we read ->mode */
	smp_mb();

	if (cpus != NULL && cpu != -1 && cpu != me &&

						 VCPU1 is scheduled to CPU 2, and running in
                                                 guest mode

	      kvm_vcpu_exiting_guest_mode(vcpu) != OUTSIDE_GUEST_MODE)
		cpumask_set_cpu(cpu, cpus);
}

       VCPU 0 send IPI to CPU1, but actually, VCPU1 is running on CPU 2.