From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 0 of 5] v2: Nested-p2m cleanups and locking changes Date: Tue, 28 Jun 2011 15:47:34 +0200 Message-ID: <4E09DB75.3040102@amd.com> References: <20110627105654.GK17634@whitby.uk.xensource.com> <4E08762A.2050801@amd.com> <20110627131528.GN17634@whitby.uk.xensource.com> <20110627154831.GS17634@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110627154831.GS17634@whitby.uk.xensource.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: Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 06/27/11 17:48, Tim Deegan wrote: > At 14:15 +0100 on 27 Jun (1309184128), Tim Deegan wrote: >> At 14:23 +0200 on 27 Jun (1309184586), Christoph Egger wrote: >>>> - Why is there a 10x increase in IPIs after this series? I don't see >>>> what sequence of events sets the relevant cpumask bits to make this >>>> happen. >>> >>> In patch 1 the code that sends the IPIs was outside of the loop and >>> moved into the loop. >> >> Well, yes, but I don't see what that causes 10x IPIs, unless the vcpus >> are burning through np2m tables very quickly indeed. Maybe removing the >> extra flushes for TLB control will do the trick. I'll make a patch... > > I think I get it - it's a race between p2m_flush_nestedp2m() on one CPU > flushing all the nested P2M tables and a VCPU on another CPU repeatedly > getting fresh ones. Try the attached patch, which should cut back the > major source of p2m_flush_nestedp2m() calls. > > Writing it, I realised that after my locking fix, p2m_flush_nestedp2m() > isn't safe because it can run in parallel with p2m_get_nestedp2m, which > reorders the array it walks. I'll have to make the LRU-fu independent > of the array order; should be easy enough but I'll hold off committing > the current series until I've done it. With Windows 7 XP mode I see a xen crash where p2m_get_nestedp2m() calls nestedhvm_vmcx_flushtlb(nv->nv_p2m) with nv->nv_p2m being NULL. nestedhvm_vmcx_flushtlb() assumes the parameter is not NULL. (XEN) Xen call trace: (XEN) [] nestedhvm_vmcx_flushtlb+0xf/0x52 (XEN) [] p2m_get_nestedp2m+0x406/0x497 (XEN) [] nestedsvm_vmcb_set_nestedp2m+0x54/0x6a (XEN) [] nsvm_vcpu_vmrun+0x984/0xf14 (XEN) [] nsvm_vcpu_switch+0x1c1/0x226 Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632