linux-kernel - Re: [Xen-devel] [PATCH v1 0/5] xen/PMU: PMU support for Xen PV guests

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: <52307DB3.7010909@oracle.com>
Date:	Wed, 11 Sep 2013 10:26:59 -0400
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
CC:	xen-devel@...ts.xen.org, linux-kernel@...r.kernel.org,
	JBeulich@...e.com
Subject: Re: [Xen-devel] [PATCH v1 0/5] xen/PMU: PMU support for Xen PV guests

On 09/11/2013 05:33 AM, David Vrabel wrote:
> On 10/09/13 16:31, Boris Ostrovsky wrote:
>> This is the Linux side of Xen PMU support for PV guests, including dom0. Only
>> kernel changes are here, toolstack patch will be provided separately.
>>
>> Here is description from the hypervisor patch submission that applies to this
>> series as well:
>>
>> This version has following limitations:
>> * For accurate profiling of dom0/Xen dom0 VCPUs should be pinned.
>> * Hypervisor code is only profiled on processors that have running dom0 VCPUs
>> on them.
>> * No backtrace support.
> These are some pretty significant limitations.   Is there a plan for how
> to remove them?

I don't have a specific plan (other than do it after this stage is 
finished) but I do
have a rough idea of what would be needed to address these.

Hypervisor changes for all three should be pretty easy.

Linux-wise, for the first one (pinned VCPU) we will probably need to make a
change in perf_sample_data. There is a reserved filed there so perhaps we
can use it to store PCPU (and maybe domainID). Plus a way to actually write
the data, probably a hook or something.

Backtrace support should also not be too bad: we can pass Xen IP stack in
the shared data area to dom0 and then again have a hook or something to
pass it to perf. (Note that backtracing is not supported for KVM neither 
so both
may benefit here)

The second one is the most difficult: We need to be able somehow to access
MSRs (and APIC, I think) on non-dom0 CPUs. Creating interface for such 
access
is not a big deal but integrating it into perf infrastructure will be a 
challenge. There
are other alternatives but they have problems as well.

-boris
--
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/