From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: jun.nakajima@intel.com, Jan Beulich <JBeulich@suse.com>,
George.Dunlap@eu.citrix.com, jacob.shin@amd.com,
eddie.dong@intel.com, dietmar.hahn@ts.fujitsu.com,
suravee.suthikulpanit@amd.com,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 11/13] x86/PMU: Handle PMU interrupts for PV guests
Date: Wed, 25 Sep 2013 11:52:22 -0400 [thread overview]
Message-ID: <524306B6.4080808@oracle.com> (raw)
In-Reply-To: <5242F5CD.3000804@citrix.com>
On 09/25/2013 10:40 AM, Andrew Cooper wrote:
> On 25/09/13 15:33, Jan Beulich wrote:
>>>>> On 20.09.13 at 11:42, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>>> Add support for handling PMU interrupts for PV guests, make these interrupts
>>> NMI instead of PMU_APIC_VECTOR vector. Depending on vpmu_mode forward the
>>> interrupts to appropriate guest (mode is VPMU_ON) or to dom0 (VPMU_DOM0).
>> Is using NMIs here a necessity? I guess not, in which case I'd really
>> like this to be a (perhaps even non-default) option controllable via
>> command line option.
>>
>>> - * This interrupt handles performance counters interrupt
>>> - */
>>> -
>>> -void pmu_apic_interrupt(struct cpu_user_regs *regs)
>>> -{
>>> - ack_APIC_irq();
>>> - vpmu_do_interrupt(regs);
>>> -}
>> So this was the only caller of vpmu_do_interrupt(); no new one gets
>> added in this patch afaics, and I don't recall having seen addition of
>> another caller in earlier patches. What's the deal?
>>
>>> @@ -99,17 +106,97 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
>>> int vpmu_do_interrupt(struct cpu_user_regs *regs)
>>> {
>>> struct vcpu *v = current;
>>> - struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>> + struct vpmu_struct *vpmu;
>>>
>>> - if ( vpmu->arch_vpmu_ops )
>>> +
>>> + /* dom0 will handle this interrupt */
>>> + if ( (vpmu_mode & XENPMU_MODE_PRIV) ||
>>> + (v->domain->domain_id >= DOMID_FIRST_RESERVED) )
>>> + {
>>> + if ( smp_processor_id() >= dom0->max_vcpus )
>>> + return 0;
>>> + v = dom0->vcpu[smp_processor_id()];
>>> + }
>>> +
>>> + vpmu = vcpu_vpmu(v);
>>> + if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>>> + return 0;
>>> +
>>> + if ( !is_hvm_domain(v->domain) || (vpmu_mode & XENPMU_MODE_PRIV) )
>>> + {
>>> + /* PV guest or dom0 is doing system profiling */
>>> + void *p;
>>> + struct cpu_user_regs *gregs;
>>> +
>>> + p = &v->arch.vpmu.xenpmu_data->pmu.regs;
>>> +
>>> + /* PV guest will be reading PMU MSRs from xenpmu_data */
>>> + vpmu_save_force(v);
>>> +
>>> + /* Store appropriate registers in xenpmu_data
>>> + *
>>> + * Note: '!current->is_running' is possible when 'set_current(next)'
>>> + * for the (HVM) guest has been called but 'reset_stack_and_jump()'
>>> + * has not (i.e. the guest is not actually running yet).
>>> + */
>>> + if ( !is_hvm_domain(current->domain) ||
>>> + ((vpmu_mode & XENPMU_MODE_PRIV) && !current->is_running) )
>>> + {
>>> + /*
>>> + * 32-bit dom0 cannot process Xen's addresses (which are 64 bit)
>>> + * and therefore we treat it the same way as a non-priviledged
>>> + * PV 32-bit domain.
>>> + */
>>> + if ( is_pv_32bit_domain(current->domain) )
>>> + {
>>> + struct compat_cpu_user_regs cmp;
>>> +
>>> + gregs = guest_cpu_user_regs();
>>> + XLAT_cpu_user_regs(&cmp, gregs);
>>> + memcpy(p, &cmp, sizeof(struct compat_cpu_user_regs));
>>> + }
>>> + else if ( (current->domain != dom0) && !is_idle_vcpu(current) &&
>>> + !(vpmu_mode & XENPMU_MODE_PRIV) )
>>> + {
>>> + /* PV guest */
>>> + gregs = guest_cpu_user_regs();
>>> + memcpy(p, gregs, sizeof(struct cpu_user_regs));
>>> + }
>>> + else
>>> + memcpy(p, regs, sizeof(struct cpu_user_regs));
>>> + }
>>> + else
>>> + {
>>> + /* HVM guest */
>>> + struct segment_register cs;
>>> +
>>> + gregs = guest_cpu_user_regs();
>>> + hvm_get_segment_register(current, x86_seg_cs, &cs);
>>> + gregs->cs = cs.attr.fields.dpl;
>>> +
>>> + memcpy(p, gregs, sizeof(struct cpu_user_regs));
>>> + }
>>> +
>>> + v->arch.vpmu.xenpmu_data->domain_id = current->domain->domain_id;
>>> + v->arch.vpmu.xenpmu_data->vcpu_id = current->vcpu_id;
>>> + v->arch.vpmu.xenpmu_data->pcpu_id = smp_processor_id();
>>> +
>>> + raise_softirq(PMU_SOFTIRQ);
>>> + vpmu_set(vpmu, VPMU_WAIT_FOR_FLUSH);
>>> +
>>> + return 1;
>>> + }
>>> + else if ( vpmu->arch_vpmu_ops )
>>> {
>>> - struct vlapic *vlapic = vcpu_vlapic(v);
>>> + /* HVM guest */
>>> + struct vlapic *vlapic;
>>> u32 vlapic_lvtpc;
>>> unsigned char int_vec;
>>>
>>> if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) )
>>> return 0;
>>>
>>> + vlapic = vcpu_vlapic(v);
>>> if ( !is_vlapic_lvtpc_enabled(vlapic) )
>>> return 1;
>>>
>> Assuming the plan is to run this in NMI context - this is _a lot_ of
>> stuff you want to do. Did you carefully audit all paths for being
>> NMI-safe?
>>
>> Jan
> vpmu_save() is not safe from an NMI context, as its non-NMI context uses
> local_irq_disable() to achieve consistency.
Sigh... hvm_get_segment_register() also appears to be unsafe. I'll will
need to
move it somewhere else.
-boris
next prev parent reply other threads:[~2013-09-25 15:50 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-20 9:41 [PATCH v2 00/13] x86/PMU: Xen PMU PV support Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 01/13] Export hypervisor symbols Boris Ostrovsky
2013-09-23 19:42 ` Konrad Rzeszutek Wilk
2013-09-23 20:06 ` Boris Ostrovsky
2013-09-24 17:40 ` Konrad Rzeszutek Wilk
2013-09-25 13:15 ` Jan Beulich
2013-09-25 14:03 ` Boris Ostrovsky
2013-09-25 14:53 ` Jan Beulich
2013-09-20 9:42 ` [PATCH v2 02/13] Set VCPU's is_running flag closer to when the VCPU is dispatched Boris Ostrovsky
2013-09-25 13:42 ` Jan Beulich
2013-09-25 14:08 ` Keir Fraser
2013-09-20 9:42 ` [PATCH v2 03/13] x86/PMU: Stop AMD counters when called from vpmu_save_force() Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 04/13] x86/VPMU: Minor VPMU cleanup Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 05/13] intel/VPMU: Clean up Intel VPMU code Boris Ostrovsky
2013-09-23 11:42 ` Dietmar Hahn
2013-09-23 19:46 ` Konrad Rzeszutek Wilk
2013-09-25 13:55 ` Jan Beulich
2013-09-25 14:39 ` Boris Ostrovsky
2013-09-25 14:57 ` Jan Beulich
2013-09-25 15:37 ` Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 06/13] x86/PMU: Add public xenpmu.h Boris Ostrovsky
2013-09-23 13:04 ` Dietmar Hahn
2013-09-23 13:16 ` Jan Beulich
2013-09-23 14:00 ` Boris Ostrovsky
2013-09-23 13:45 ` Boris Ostrovsky
2013-09-25 14:04 ` Jan Beulich
2013-09-25 15:59 ` Boris Ostrovsky
2013-09-25 16:08 ` Jan Beulich
2013-09-30 13:25 ` Boris Ostrovsky
2013-09-30 13:30 ` Jan Beulich
2013-09-30 13:55 ` Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 07/13] x86/PMU: Make vpmu not HVM-specific Boris Ostrovsky
2013-09-25 14:05 ` Jan Beulich
2013-09-25 14:49 ` Boris Ostrovsky
2013-09-25 14:57 ` Jan Beulich
2013-09-20 9:42 ` [PATCH v2 08/13] x86/PMU: Interface for setting PMU mode and flags Boris Ostrovsky
2013-09-25 14:11 ` Jan Beulich
2013-09-25 14:55 ` Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 09/13] x86/PMU: Initialize PMU for PV guests Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 10/13] x86/PMU: Add support for PMU registes handling on " Boris Ostrovsky
2013-09-23 13:50 ` Dietmar Hahn
2013-09-25 14:23 ` Jan Beulich
2013-09-25 15:03 ` Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 11/13] x86/PMU: Handle PMU interrupts for " Boris Ostrovsky
2013-09-25 14:33 ` Jan Beulich
2013-09-25 14:40 ` Andrew Cooper
2013-09-25 15:52 ` Boris Ostrovsky [this message]
2013-09-25 15:19 ` Boris Ostrovsky
2013-09-25 15:25 ` Jan Beulich
2013-09-20 9:42 ` [PATCH v2 12/13] x86/PMU: Save VPMU state for PV guests during context switch Boris Ostrovsky
2013-09-20 9:42 ` [PATCH v2 13/13] x86/PMU: Move vpmu files up from hvm directory Boris Ostrovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524306B6.4080808@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dietmar.hahn@ts.fujitsu.com \
--cc=eddie.dong@intel.com \
--cc=jacob.shin@amd.com \
--cc=jun.nakajima@intel.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.