[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 15/19] x86/VPMU: Add privileged PMU mode
>>> On 13.05.14 at 17:53, <boris.ostrovsky@xxxxxxxxxx> wrote: > @@ -128,16 +130,23 @@ int vpmu_do_interrupt(struct cpu_user_regs *regs) > struct vcpu *v = current; > struct vpmu_struct *vpmu; > > - /* dom0 will handle interrupt for special domains (e.g. idle domain) */ > - if ( v->domain->domain_id >= DOMID_FIRST_RESERVED ) > + /* > + * dom0 will handle interrupt for special domains (e.g. idle domain) or, > + * in XENPMU_MODE_PRIV, for everyone. > + */ > + if ( (vpmu_mode & XENPMU_MODE_PRIV) || > + (v->domain->domain_id >= DOMID_FIRST_RESERVED) ) > v = hardware_domain->vcpu[smp_processor_id() % > hardware_domain->max_vcpus]; > > vpmu = vcpu_vpmu(v); > - if ( !is_hvm_domain(v->domain) ) > + 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 */ > - const struct cpu_user_regs *gregs; > + struct cpu_user_regs *gregs; Stray/unintended change? > @@ -148,34 +157,62 @@ int vpmu_do_interrupt(struct cpu_user_regs *regs) > err = vpmu->arch_vpmu_ops->arch_vpmu_save(v); > vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED); > > - /* Store appropriate registers in xenpmu_data */ > - if ( is_pv_32bit_domain(current->domain) ) > + if ( !is_hvm_domain(current->domain) ) > { > - /* > - * 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. > - */ > - struct compat_cpu_user_regs *cmp; > - > - gregs = guest_cpu_user_regs(); > + /* Store appropriate registers in xenpmu_data */ > + if ( is_pv_32bit_domain(current->domain) ) > + { > + gregs = guest_cpu_user_regs(); > + > + if ( (vpmu_mode & XENPMU_MODE_PRIV) && > + !is_pv_32bit_domain(v->domain) ) > + memcpy(&v->arch.vpmu.xenpmu_data->pmu.r.regs, > + gregs, sizeof(struct cpu_user_regs)); > + else > + { > + /* > + * 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. > + */ > + > + struct compat_cpu_user_regs *cmp; > + > + cmp = (struct compat_cpu_user_regs *) > + &v->arch.vpmu.xenpmu_data->pmu.r.regs; > + XLAT_cpu_user_regs(cmp, gregs); > + memcpy(&v->arch.vpmu.xenpmu_data->pmu.r.regs, > + &cmp, sizeof(struct compat_cpu_user_regs)); > + } > + } > + else if ( !is_hardware_domain(current->domain) && > + !is_idle_vcpu(current) ) > + { > + /* PV guest */ /* 64-bit PV guest */? > + gregs = guest_cpu_user_regs(); > + memcpy(&v->arch.vpmu.xenpmu_data->pmu.r.regs, > + gregs, sizeof(struct cpu_user_regs)); > + } > + else > + memcpy(&v->arch.vpmu.xenpmu_data->pmu.r.regs, > + regs, sizeof(struct cpu_user_regs)); > > - cmp = (void *)&v->arch.vpmu.xenpmu_data->pmu.r.regs; > - XLAT_cpu_user_regs(cmp, gregs); > - memcpy(&v->arch.vpmu.xenpmu_data->pmu.r.regs, > - &cmp, sizeof(struct compat_cpu_user_regs)); > + gregs = &v->arch.vpmu.xenpmu_data->pmu.r.regs; > + gregs->cs = (current->arch.flags & TF_kernel_mode) ? 0 : 0x3; Ah, no - you want to modify the structure here. But you could do this directly on the ->pmu.r.regs field rather than first latching the pointer. And as said before, it doesn't really look correct to simply set ->cs to just the RPL, especially without any comment explaining why this is (a) being done and (b) correct. > } > - else if ( !is_hardware_domain(current->domain) && > - !is_idle_vcpu(current) ) > + else > { > - /* PV guest */ > + /* HVM guest */ > + struct segment_register cs; > + > gregs = guest_cpu_user_regs(); > memcpy(&v->arch.vpmu.xenpmu_data->pmu.r.regs, > gregs, sizeof(struct cpu_user_regs)); > + > + hvm_get_segment_register(current, x86_seg_cs, &cs); > + gregs = &v->arch.vpmu.xenpmu_data->pmu.r.regs; > + gregs->cs = cs.attr.fields.dpl; Same here then obviously. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |