From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] nestedhvm: ASID emulation Date: Wed, 13 Apr 2011 16:05:20 +0100 Message-ID: References: <4DA5B299.3060904@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DA5B299.3060904@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Egger Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 13/04/2011 15:26, "Christoph Egger" wrote: > On 04/13/11 15:27, Keir Fraser wrote: >> On 13/04/2011 11:37, "Christoph Egger" wrote: >> > We talk about a win of about 1000 cycles per VMRUN and another 1000 > cycles per VMEXIT emulation. > > That's a speedup of about 10% for each VMRUN and about 20% for each > VMEXIT emulation. Is this measurable on a macro benchmark? I mean this looks like a micro-optimisation on a feature that noone is going to use for serious performance work anyway. > 4. nestedhvm is enabled and we are going to run l2 guest > > We run the l1 guest in the last call. The asid generation may have > changed by then. In this case the current nv_n2asid number is stale > and the value of data->next_asid is <= of nv->nv_n2asid. How do you know for sure that next_asid will be <= nv_n2asid in this case? What if other VCPUs have run meanwhile, and next_asid has been incremented multiple times until it is greather than nv_n2asid? -- Keir > The the value of nv->nv_n2asid is valid if l1 guest doesn't change > the virtual asid (= asid number in the virtual vmcb) and > data->next_asid is larger than nv->nv_n2asid. In this case > just reuse the same hw ASID that has been used from the last > VMRUN emulation. > > 5. nestedhvm is enabled and we are going to run l2 guest again > > The same hw ASID should be reused unless the generation changed because > the nestedp2m got flushed or the vcpu moved to a different physical cpu, > for example. > But the hw ASID number may never match the hw ASID used to run the l1 guest. > > > In all cases we have to verify that the > >> I wouldn't bother fixing #2 unless there's a convincing answer for #1. >> >> -- Keir >