|
[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 |