Re: [Xen-devel] [PATCH 2/2] AMD/VPMU: Keep reserved MSR bits untouched but allow the rest to be written

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.08.16 at 19:00, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 08/08/2016 11:54 AM, Jan Beulich wrote:
>>>>> On 08.08.16 at 17:28, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 08/08/2016 11:10 AM, Jan Beulich wrote:
>>>>>>> On 08.08.16 at 16:10, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>> On 08/08/2016 09:56 AM, Jan Beulich wrote:
>>>>>>>>> On 08.08.16 at 15:41, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>>>> While AMD APM suggests that reserved MSR bits are not supposed to be
>>>>>>> touched, it is not clear how (or whether) HW enforces this for PMU
>>>>>>> registers. At least on some family 10h processors writes of these bits
>>>>>>> are apparently ignored: guests (such as Linux) assume that the bits
>>>>>>> are zero and write the MSRs with that assumption in mind even though
>>>>>>> the bits are set by the time OS/hypervisor starts runnning.
>>>>>> So how did these bits become non-zero then?
>>>>> Apparently one of the systems in our lab always had somewhat strange
>>>>> post-BIOS state of these registers, with some bits (I think 19, can't
>>>>> remember now) set. I never picked this up before since we don't really
>>>>> test VPMU, we just initialize it and failure to initialize is non-fatal.
>>>> Hm, if we find reserved bits set during boot, maybe we could
>>>> simply record that and allow those bits to retain their non-zero
>>>> value during later writes (along with getting cleared to zero)?
>>> But that's exactly what I am trying to do, no? ctrl_rsvd[] is state of
>>> those bits when the hypervisor first reads the registers.
>> Not really - you always or in the settings you found on boot.
> 
> But this is done after a register has its reserved bits cleared, so only
> reserved bits that were set on boot are set again:
> 
>     msr_content = (msr_content & ~CTRL_RSVD_MASK) | ctrl_rsvd[idx];

But that's different from what I said we'd probably prefer: "allow
those bits to retain their non-zero value during later writes (along
with getting cleared to zero)".

>>>>>> Independent of that I think the relaxation would better only be done
>>>>>> for those older CPUs.
>>>>> Why? This can easily happen on any family.
>>>> Can it? Your description reads more like this is an exception, not
>>>> the rule. I'd prefer for us to be conservative here. Suravee?
>>> So my theory is that even when bits are declared reserved, BIOS/POST
>>> (who presumably know exactly how HW behaves and therefore know that, for
>>> example, HW will ignore those bits) for whatever reason may flip those
>>> bits and not restore them to zero. So it's really not HW property but
>>> firmware not cleaning up. If that's the case, however, we know that it's
>>> safe to set the bits since BIOS just did that.
>> ... this is not a really correct statement, as it neglects the possibility
>> that certain bit combinations are invalid.
> 
> Not sure I understand why: we save into ctrl_rsvd the combination (of
> reserved bits)
> that we know is valid, otherwise we wouldn't have read it.

But those set bits in the reserved group could conflict with certain
settings of non-reserved bits. Anyway, without input from AMD I
don't think we're going to come to a conclusion here, not the least
because I'm not convinced PRM and BKDG can really be relied upon
wrt the distinction between "reserved" and "mbz".

Jan


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