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

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.

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



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