From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] nestedhvm: ASID emulation Date: Wed, 13 Apr 2011 17:22:30 +0100 Message-ID: References: <4DA5BEF4.3060504@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DA5BEF4.3060504@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 16:19, "Christoph Egger" wrote: > On 04/13/11 17:05, Keir Fraser wrote: >> On 13/04/2011 15:26, "Christoph Egger" wrote: >> >> Is this measurable on a macro benchmark? > > I measured this with xentrace while l2 guest is booting. > > The speedup is noticable on the end-user side just by the feeling on how > fast the l2 guest reacts on user input. Yikes. Does nestedhvm suck really badly then? I can't believe this patch alone gets you from sucky to good performance. Is it an improvement from sucky to not-quite-as-sucky? >> 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? > > In that case curr->arch.hvm_vcpu.asid_generation is not equal to > data->core_asid_generation and a new hw ASID number is assigned > regardless of the values of data->next_asid and nv_n2asid. What if nv_n2asid wast last assigned on a previous generation, but nv_n1asid was assigned from the current generation? Then you'd have next_asid > nv_n2asid, but nv_n2asid is stale. -- Keir > Christoph > >> >> -- 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 >>> >> >> >> >