Re: [PATCH v17 14/23] x86/VPMU: Initialize VPMUs with __initcall

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 01/30/2015 09:54 AM, Jan Beulich wrote:
>>>> On 05.01.15 at 22:44, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -497,3 +497,39 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>>
>>       return ret;
>>   }
>> +
>> +static int __init vpmu_init(void)
>> +{
>> +    int vendor = current_cpu_data.x86_vendor;
>> +
>> +    if ( vpmu_mode == XENPMU_MODE_OFF )
>> +    {
>> +        printk(XENLOG_INFO "VPMU: disabled\n");
>> +        return 0;
>> +    }
>> +
>> +    switch ( vendor )
>> +    {
>> +    case X86_VENDOR_AMD:
>> +        if ( amd_vpmu_init() )
>> +           vpmu_mode = XENPMU_MODE_OFF;
>> +        break;
>> +    case X86_VENDOR_INTEL:
>> +        if ( core2_vpmu_init() )
>> +           vpmu_mode = XENPMU_MODE_OFF;
>> +        break;
>> +    default:
>> +        printk(XENLOG_WARNING "VPMU: Unknown CPU vendor: %d\n", vendor);
>> +        vpmu_mode = XENPMU_MODE_OFF;
>> +        break;
>
> return 0;
>
> (i.e. avoid printing another message below)
>
>> +    }
>> +
>> +    if ( vpmu_mode == XENPMU_MODE_OFF )
>> +        printk(XENLOG_WARNING "VPMU: Disabling due to initialization error\n");
>
> We repeatedly find that not printing at least a vague indication of
> what went wrong makes problem analysis quite a bit more difficult.
> It won't cost much to include the actual error code here.


The actual error is printed by the architectural code (i.e. 
amd_vpmu_init()/core2_vpmu_init()).


-boris