Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753550AbbGBROo (ORCPT ); Thu, 2 Jul 2015 13:14:44 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:26957 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753575AbbGBROg (ORCPT ); Thu, 2 Jul 2015 13:14:36 -0400 Message-ID: <55957169.1040303@oracle.com> Date: Thu, 02 Jul 2015 13:14:17 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: David Vrabel , konrad.wilk@oracle.com CC: kevin.tian@intel.com, linux-kernel@vger.kernel.org, dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH v5 3/6] xen/PMU: Initialization code for Xen PMU References: <1435848816-3323-1-git-send-email-boris.ostrovsky@oracle.com> <1435848816-3323-4-git-send-email-boris.ostrovsky@oracle.com> <55956515.5050103@citrix.com> In-Reply-To: <55956515.5050103@citrix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1555 Lines: 42 On 07/02/2015 12:21 PM, David Vrabel wrote: > On 02/07/15 15:53, Boris Ostrovsky wrote: >> Map shared data structure that will hold CPU registers, VPMU context, >> V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills >> this information in its handler and passes it to the guest for further >> processing. >> >> Set up PMU VIRQ. >> >> Now that perf infrastructure will assume that PMU is available on a PV >> guest we need to be careful and make sure that accesses via RDPMC >> instruction don't cause fatal traps by the hypervisor. Provide a nop >> RDPMC handler. >> >> For the same reason avoid issuing a warning on a write to APIC's LVTPC. >> >> Both of these will be made functional in later patches. > [...] >> + rc = bind_virq_to_irqhandler(VIRQ_XENPMU, cpu, >> + xen_pmu_irq_handler, >> + IRQF_PERCPU|IRQF_NOBALANCING, >> + pmu_name, NULL); > If you bind a VIRQ as IRQF_PERCPU it can only be safely unbound on the > CPU it is bound to (because the percpu handler does not take the > desc->lock). This is a true per-cpu VIRQ and we only unbind it on cpu_die() path so I think IRQF_PERCPU should be safe, no? (it behaves similar to VIRQ_TIMER in how/when it is unbound). -boris > > Otherwise, Reviewed-by: David Vrabel > > David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/