All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
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
Subject: Re: [PATCH v14 for-xen-4.5 17/21] x86/VPMU: Handle PMU interrupts for PV guests
Date: Mon, 27 Oct 2014 15:43:19 -0400	[thread overview]
Message-ID: <544EA057.1030007@oracle.com> (raw)
In-Reply-To: <544E86D90200007800042917@mail.emea.novell.com>

On 10/27/2014 12:54 PM, Jan Beulich wrote:
>>>> On 17.10.14 at 23:18, <boris.ostrovsky@oracle.com> 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.

>
>>   void vpmu_do_interrupt(struct cpu_user_regs *regs)
>>   {
>> -    struct vcpu *v = current;
>> -    struct vpmu_struct *vpmu = vcpu_vpmu(v);
>> +    struct vcpu *sampled = current, *sampling;
>> +    struct vpmu_struct *vpmu;
>> +
>> +    /* dom0 will handle interrupt for special domains (e.g. idle domain) */
>> +    if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
>> +    {
>> +        sampling = choose_hwdom_vcpu();
>> +        if ( !sampling )
>> +            return;
>> +    }
>> +    else
>> +        sampling = sampled;
>> +
>> +    vpmu = vcpu_vpmu(sampling);
>> +    if ( !is_hvm_vcpu(sampling) )
>> +    {
>> +        /* PV(H) guest */
>> +        const struct cpu_user_regs *cur_regs;
>> +        uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
>> +        uint32_t domid = DOMID_SELF;
>> +
>> +        if ( !vpmu->xenpmu_data )
>> +            return;
>> +
>> +        if ( *flags & PMU_CACHED )
>> +            return;
>> +
>> +        if ( is_pvh_vcpu(sampling) &&
>> +             !vpmu->arch_vpmu_ops->do_interrupt(regs) )
>> +            return;
>> +
>> +        /* PV guest will be reading PMU MSRs from xenpmu_data */
>> +        vpmu_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
>> +        vpmu->arch_vpmu_ops->arch_vpmu_save(sampling);
>> +        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
>> +
>> +        *flags = 0;
>> +
>> +        /* Store appropriate registers in xenpmu_data */
>> +        /* FIXME: 32-bit PVH should go here as well */
>> +        if ( is_pv_32bit_vcpu(sampling) )
>> +        {
>> +            /*
>> +             * 32-bit dom0 cannot process Xen's addresses (which are 64 bit)
>> +             * and therefore we treat it the same way as a non-privileged
>> +             * PV 32-bit domain.
>> +             */
>> +            struct compat_pmu_regs *cmp;
>> +
>> +            cur_regs = guest_cpu_user_regs();
>> +
>> +            cmp = (void *)&vpmu->xenpmu_data->pmu.r.regs;
>> +            cmp->ip = cur_regs->rip;
>> +            cmp->sp = cur_regs->rsp;
>> +            cmp->flags = cur_regs->eflags;
>> +            cmp->ss = cur_regs->ss;
>> +            cmp->cs = cur_regs->cs;
>> +            if ( (cmp->cs & 3) != 1 )
>> +                *flags |= PMU_SAMPLE_USER;
>> +        }
>> +        else
>> +        {
>> +            struct xen_pmu_regs *r = &vpmu->xenpmu_data->pmu.r.regs;
>> +
>> +            if ( (vpmu_mode & XENPMU_MODE_SELF) )
>> +                cur_regs = guest_cpu_user_regs();
>> +            else if ( (regs->rip >= XEN_VIRT_START) &&
>> +                      (regs->rip < XEN_VIRT_END) &&
>> +                      is_hardware_domain(sampling->domain))
> I'm pretty sure that already on the previous round I said that using
> only RIP for determining whether the sample occurred in hypervisor
> context is not enough.

Hmm, I did change this to !guest_mode(). But must have reverted it when 
doing rebasing.


>
>> +            {
>> +                cur_regs = regs;
>> +                domid = DOMID_XEN;
>> +            }
>> +            else
>> +                cur_regs = guest_cpu_user_regs();
>> +
>> +            r->ip = cur_regs->rip;
>> +            r->sp = cur_regs->rsp;
>> +            r->flags = cur_regs->eflags;
>> +
>> +            if ( !has_hvm_container_vcpu(sampled) )
>> +            {
>> +                r->ss = cur_regs->ss;
>> +                r->cs = cur_regs->cs;
>> +                if ( !(sampled->arch.flags & TF_kernel_mode) )
>> +                    *flags |= PMU_SAMPLE_USER;
>> +            }
>> +            else
>> +            {
>> +                struct segment_register seg;
>> +
>> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
>> +                r->cs = seg.sel;
>> +                if ( (r->cs & 3) != 0 )
>> +                    *flags |= PMU_SAMPLE_USER;
> So is the VM86 mode case here intentionally being ignored?

We pass EFLAGS so the guest can check the VM bit. Is this not sufficient?

> And is
> there a particular reason you look at the selector's RPL instead of
> DPL, and CS instead of SS?

Should be DPL indeed. But why is SS better than CS?

-boris

  reply	other threads:[~2014-10-27 19:43 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 21:17 [PATCH v14 for-xen-4.5 00/21] x86/PMU: Xen PMU PV(H) support Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 01/21] common/symbols: Export hypervisor symbols to privileged guest Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 02/21] x86/VPMU: Manage VPMU_CONTEXT_SAVE flag in vpmu_save_force() Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 03/21] x86/VPMU: Set MSR bitmaps only for HVM/PVH guests Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 04/21] x86/VPMU: Make vpmu macros a bit more efficient Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 05/21] intel/VPMU: Clean up Intel VPMU code Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 06/21] vmx: Merge MSR management routines Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 07/21] x86/VPMU: Handle APIC_LVTPC accesses Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 08/21] intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL should be initialized to zero Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 09/21] x86/VPMU: Add public xenpmu.h Boris Ostrovsky
2014-10-24 16:00   ` Jan Beulich
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 10/21] x86/VPMU: Make vpmu not HVM-specific Boris Ostrovsky
2014-10-17 21:17 ` [PATCH v14 for-xen-4.5 11/21] x86/VPMU: Interface for setting PMU mode and flags Boris Ostrovsky
2014-10-27 16:24   ` Jan Beulich
2014-10-27 18:52     ` Boris Ostrovsky
2014-10-28  8:29       ` Jan Beulich
2014-10-28 16:56         ` Boris Ostrovsky
2014-10-29  8:14           ` Jan Beulich
2014-10-29 14:22             ` Boris Ostrovsky
2014-10-29 16:50               ` Jan Beulich
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 12/21] x86/VPMU: Initialize AMD and Intel VPMU with __initcall Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 13/21] x86/VPMU: Initialize PMU for PV(H) guests Boris Ostrovsky
2014-10-27 16:38   ` Jan Beulich
2014-10-27 19:21     ` Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 14/21] x86/VPMU: Save VPMU state for PV guests during context switch Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 15/21] x86/VPMU: When handling MSR accesses, leave fault injection to callers Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 16/21] x86/VPMU: Add support for PMU register handling on PV guests Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 17/21] x86/VPMU: Handle PMU interrupts for " Boris Ostrovsky
2014-10-27 16:54   ` Jan Beulich
2014-10-27 19:43     ` Boris Ostrovsky [this message]
2014-10-28  9:30       ` Jan Beulich
2014-10-28 17:08         ` Boris Ostrovsky
2014-10-29  8:19           ` Jan Beulich
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 18/21] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 19/21] x86/VPMU: Add privileged PMU mode Boris Ostrovsky
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 20/21] x86/VPMU: NMI-based VPMU support Boris Ostrovsky
2014-10-28 10:51   ` Jan Beulich
2014-10-17 21:18 ` [PATCH v14 for-xen-4.5 21/21] x86/VPMU: Move VPMU files up from hvm/ directory Boris Ostrovsky
2014-10-28 10:52   ` Jan Beulich
2014-10-27  7:38 ` [PATCH v14 for-xen-4.5 00/21] x86/PMU: Xen PMU PV(H) support Dietmar Hahn
2014-10-27 13:47   ` 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=544EA057.1030007@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=dietmar.hahn@ts.fujitsu.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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.