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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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];


>
>> There is one hole here (and it always was there) in that we assume that
>> all processors in the system behave the same in this regard. I.e. we
>> only read ctrl_rsvd on the boot processor.
> If the processors are of exactly the same stepping that shouldn't
> by itself not be a problem (and mixed steppings are frwoned upon
> anyway). However ...
>
>>>>> 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.

-boris



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