From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sheng Yang <sheng@linux.intel.com>
Subject: Re: [PATCH v3] KVM: VMX: Execute WBINVD to keep data consistency with assigned devices
Date: Mon, 28 Jun 2010 14:56:05 +0800
Message-ID: <201006281456.05750.sheng@linux.intel.com>
References: <1277696187-3571-1-git-send-email-sheng@linux.intel.com> <201006281442.35437.sheng@linux.intel.com> <4C2847A6.3040500@redhat.com>
Mime-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Joerg Roedel <joerg.roedel@amd.com>, kvm@vger.kernel.org,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mga02.intel.com ([134.134.136.20]:10992 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753216Ab0F1G56 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 28 Jun 2010 02:57:58 -0400
In-Reply-To: <4C2847A6.3040500@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Monday 28 June 2010 14:56:38 Avi Kivity wrote:
> On 06/28/2010 09:42 AM, Sheng Yang wrote:
> >>> +static void wbinvd_ipi(void *garbage)
> >>> +{
> >>> +	wbinvd();
> >>> +}
> >> 
> >> Like Jan mentioned, this is quite heavy.  What about a clflush() loop
> >> instead?  That may take more time, but at least it's preemptible.  Of
> >> course, it isn't preemptible in an IPI.
> > 
> > I think this kind of behavior happened rarely, and most recent processor
> > should have WBINVD exit which means it's an IPI... So I think it's maybe
> > acceptable here.
> 
> Several milliseconds of non-responsiveness may not be acceptable for
> some applications.  So I think queue_work_on() and a clflush loop is
> better than an IPI and wbinvd.

OK... Would update it in the next version.

--
regards
Yang, Sheng

> 
> >>> +
> >>> 
> >>>    void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> >>>    {
> >>> 
> >>> +	/* Address WBINVD may be executed by guest */
> >>> +	if (vcpu->kvm->arch.iommu_domain) {
> >>> +		if (kvm_x86_ops->has_wbinvd_exit())
> >>> +			cpu_set(cpu, vcpu->arch.wbinvd_dirty_mask);
> >>> +		else if (vcpu->cpu != -1)
> >>> +			smp_call_function_single(vcpu->cpu,
> >>> +					wbinvd_ipi, NULL, 1);
> >> 
> >> Is there any point to doing this if !has_wbinvd_exit()?  The vcpu might
> >> not have migrated in time, so the cache is flushed too late.
> > 
> > For the !has_wbinvd_exit(), the instruction would be executed by guest
> > and flush the current processor immediately. And we can ensure that it's
> > clean in the last CPU, so we're fine.
> 
> Ah, yes.