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

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

Jan


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