WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
From: "Michael A Fetterman" <Michael.Fetterman@xxxxxxxxxxxx>
Date: Tue, 9 Oct 2007 10:23:37 +0100
Cc: "Su, Disheng" <disheng.su@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 09 Oct 2007 02:24:17 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=B3ND+B0l4BXnQiobB0Tv4UQAbYtLNyDeaxj+54R4h/Y=; b=Vgz0O5RF73snnFeoEYHTrM9HQhbOxVpCrmB6TFNTOo8S2zy4Bot0+0iAqw4WsBWs9ku2CHrgH/PXrIbD759/dcSSRcl/qn6zNICrqdTDsiRMRSXmjb8kovn+A3RkIV3RYk1ctbqZMV9lD9V7NpPAXykYc4LHSsVzo5Zrn7FqY1g=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=h5+I7MSdCpEh263rjAd/wzZlSs8cGjQdw3Xtzmm5ZVmd4NqSicOKtBst+nlqNZBbGs2m/U1wup3QijSJLdq66lYf8k5yvWAo8eJfdjtnGZdFCYlos56Py5gN67IZS1xxC/WCRaQGRZPLeG4H/qbEbQkFamOJR3s7TWSfu2Kc9m0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C330F6FA.E98B%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <10EA09EFD8728347A513008B6B0DA77A0231BECE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C330F6FA.E98B%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > But, yes this is really a good point. So we need to do WBINVD when VP
> > migrates (of course for pass-through domain only), while the prefered
> > approach is to pin VCPU on pCPUs.
>
> Or WBINVD all CPUs when a VCPU executes WBINVD. Or explicitly track dirty
> caches for each vCPU.

I shutter to think of allowing a guest to cause a WBINVD.

In modern systems (8M+ of cache, etc), it can take 4+ milliseconds to execute.
I dare say it could, in a worst case scenerio, be even worse if you
did it on multiple
CPUs or hyperthreads at once.  And the cpu is non-interruptable the entire time.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel