From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v5] KVM: VMX: Execute WBINVD to keep data consistency with assigned devices Date: Tue, 29 Jun 2010 16:50:49 +0300 Message-ID: <4C29FA39.8060908@redhat.com> References: <4C286CCE.10309@redhat.com> <1277781419-13227-1-git-send-email-sheng@linux.intel.com> <20100629132541.GB27338@amt.cnet> <4C29F503.7020400@redhat.com> <20100629133516.GC28951@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sheng Yang , Jan Kiszka , Joerg Roedel , kvm@vger.kernel.org, "Yaozu (Eddie) Dong" To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40619 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755992Ab0F2Nu4 (ORCPT ); Tue, 29 Jun 2010 09:50:56 -0400 In-Reply-To: <20100629133516.GC28951@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 06/29/2010 04:35 PM, Marcelo Tosatti wrote: >>> >>> work_on_cpu() loop instead of smp_call_function_many(), to avoid executing >>> wbinvd with interrupts disabled. >>> >> Why? wbinvd is not interruptible. >> > Right. But still, smp_call_function_many() is going to busy-spin until > the target CPUs finish their work, while work_on_cpu() will schedule. > > Good point. So in the worst case we double the hit. > Also the IPI request has to handled immediately, bypassing the > scheduler. > We're screwed on that point in any case, once wbinvd starts the scheduler is bypassed. But work_on_cpu() has its own problems. It creates a kthread (perhaps not too bad). Maybe queue_work_on()? btw, smp_call_function_many() appears not to run the function on the current cpu. -- error compiling committee.c: too many arguments to function