linux-kernel - Re: [Xen-devel] [PATCH v5 3/6] xen/PMU: Initialization code for Xen PMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55957169.1040303@oracle.com>
Date:	Thu, 02 Jul 2015 13:14:17 -0400
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>, konrad.wilk@...cle.com
CC:	kevin.tian@...el.com, linux-kernel@...r.kernel.org,
	dietmar.hahn@...fujitsu.com, xen-devel@...ts.xen.org,
	jbeulich@...e.com
Subject: Re: [Xen-devel] [PATCH v5 3/6] xen/PMU: Initialization code for Xen
 PMU

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.vrabel@...rix.com>
>
> David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/