Re: [Xen-devel] [PATCH v22 11/14] x86/VPMU: Handle PMU interrupts for PV(H) guests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.05.15 at 20:09, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 05/26/2015 12:24 PM, Jan Beulich wrote:
>>>>> On 21.05.15 at 19:57, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> @@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
>>>       }
>>>   }
>>>   
>>> -static void amd_vpmu_load(struct vcpu *v)
>>> +static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
>>>   {
>>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>> -    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
>>> -    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
>>> +    struct xen_pmu_amd_ctxt *ctxt;
>>> +    uint64_t *ctrl_regs;
>>> +    unsigned int i;
>>>   
>>>       vpmu_reset(vpmu, VPMU_FROZEN);
>>>   
>>> -    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
>>> +    if ( !from_guest && vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
>>>       {
>>> -        unsigned int i;
>>> +        ctxt = vpmu->context;
>>> +        ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
>>>   
>>>           for ( i = 0; i < num_counters; i++ )
>>>               wrmsrl(ctrls[i], ctrl_regs[i]);
>>>   
>>> -        return;
>>> +        return 0;
>>> +    }
>>> +
>>> +    if ( from_guest )
>>> +    {
>>> +        ASSERT(!is_hvm_vcpu(v));
>>> +
>>> +        ctxt = &vpmu->xenpmu_data->pmu.c.amd;
>>> +        ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
>>> +        for ( i = 0; i < num_counters; i++ )
>>> +        {
>>> +            if ( is_pmu_enabled(ctrl_regs[i]) )
>>> +            {
>>> +                vpmu_set(vpmu, VPMU_RUNNING);
>>> +                break;
>>> +            }
>>> +        }
>>> +
>>> +        if ( i == num_counters )
>>> +            vpmu_reset(vpmu, VPMU_RUNNING);
>>> +
>>> +        memcpy(vpmu->context, &vpmu->xenpmu_data->pmu.c.amd, ctxt_sz);
>>>       }
>>>   
>>>       vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
>>>   
>>>       context_load(v);
>>> +
>>> +    return 0;
>>>   }
>> So no verification needed at all on the AMD side? If so,
> 
> 
> So I went back to BKDGs and it looks like some models of family 15 
> redefined one of the bits from Reserved to MBZ so I think I'll need to 
> verify that bit now.
> 
> It's rather strange that this bit (MSRC001_0200[19]) is reserved for 
> models 00h-0Fh and 30-3Fh but is MBZ for 10h-1Fh. It is also reserved 
> for families 10h and 16h. I don't have access to the MBZ models so I 
> can't test whether it is indeed MBZ or a typo in the spec (I can 
> certainly write it with 1 on family 10h and 15h/model2).

But no matter whether reserved or MBZ, you'd need to guard
against the guest writing values there anyway. The only
difference would be whether to expect zeros or no change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel