[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 05/16] x86/VPMU: Handle APIC_LVTPC accesses
>>> On 13.01.14 at 16:04, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote: > On 01/13/2014 08:28 AM, Jan Beulich wrote: >>>>> On 06.01.14 at 20:24, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote: >>> Update APIC_LVTPC vector when HVM guest writes to it. >>> >>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> > > ... > >>> +void vpmu_lvtpc_update(uint32_t val) >>> +{ >>> + struct vpmu_struct *vpmu = vcpu_vpmu(current); >>> + >>> + vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED); >>> + apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc); >>> +} >>> + >>> int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content) >>> { >>> struct vpmu_struct *vpmu = vcpu_vpmu(current); >>> @@ -227,19 +235,21 @@ void vpmu_initialise(struct vcpu *v) >>> case X86_VENDOR_AMD: >>> if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 ) >>> opt_vpmu_enabled = 0; >>> - break; >>> + return; >>> >>> case X86_VENDOR_INTEL: >>> if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 ) >>> opt_vpmu_enabled = 0; >>> - break; >>> + return; >>> >>> default: >>> printk("VPMU: Initialization failed. " >>> "Unknown CPU vendor %d\n", vendor); >>> opt_vpmu_enabled = 0; >>> - break; >>> + return; >>> } >>> + >>> + vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED; >>> } >> So what is this good for? All code paths above use "return" now, >> hence how would execution get here? > > Yes, it shouldn't be here. I could move it up but since we are now > updating LVTPC explicitly when a guest is writing APIC I think I can > just drop it altogether. As long as the mask bit gets properly set somewhere, not adding it here or anywhere else seems fine to me. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |