From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v14 for-xen-4.5 17/21] x86/VPMU: Handle PMU interrupts for PV guests Date: Tue, 28 Oct 2014 13:08:50 -0400 Message-ID: <544FCDA2.9070803@oracle.com> References: <1413580689-2750-1-git-send-email-boris.ostrovsky@oracle.com> <1413580689-2750-18-git-send-email-boris.ostrovsky@oracle.com> <544E86D90200007800042917@mail.emea.novell.com> <544EA057.1030007@oracle.com> <544F703E0200007800042B4E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <544F703E0200007800042B4E@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com, andrew.cooper3@citrix.com, tim@xen.org, dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org, Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On 10/28/2014 05:30 AM, Jan Beulich wrote: >>>> On 27.10.14 at 20:43, wrote: >> On 10/27/2014 12:54 PM, Jan Beulich wrote: >>>>>> On 17.10.14 at 23:18, wrote: >>>> --- a/xen/arch/x86/hvm/vpmu.c >>>> +++ b/xen/arch/x86/hvm/vpmu.c >>>> @@ -81,46 +81,206 @@ static void __init parse_vpmu_param(char *s) >>>> >>>> void vpmu_lvtpc_update(uint32_t val) >>>> { >>>> - struct vpmu_struct *vpmu = vcpu_vpmu(current); >>>> + struct vcpu *curr = current; >>>> + struct vpmu_struct *vpmu = vcpu_vpmu(curr); >>>> >>>> vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED); >>>> - apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc); >>>> + >>>> + /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending >> */ >>>> + if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data || >>>> + !(vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) ) >>> Isn't this the pointer that pvpmu_finish() deallocates (and needs to >>> clear? If so, there's a race between it being cleared and used. If you >>> need it in places like this, perhaps you'd be better off never clearing >>> it and leaving the MFN allocated? >> This will be one of the places that check for VPMU_CONTEXT_ALLOCATED. > But how will adding this check make this race free? > This VCPU is paused while we are tearing down its pvpmu so we can't be in the middle if this (or other, such as vpmu_do_msr()) hypercall, can we? Or it's not paused if the VCPU is the same one that is doing the teardown. In which case we certainly are not in this hypercall. So, in fact, the check for VPMU_CONTEXT_ALLOCATED may not be needed at all. -boris