Re: [Xen-devel] Xen 4.2 TODO / Release Plan

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.08.12 at 19:06, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> As for patch 5, it cannot be reordered w/o patch 3 checked in (patch 5 is 
> for save/restore MCi_CTL2, a newly added MSR at patch 3). In fact we could 
> remove patch 5 totally, and don't add MCi_CTL2 (this MSR is nothing to do 
> with vmce logic itself, the only reason why we add it in new vmce is to get 
> perfromance benefit (but very trivial), so it's OK not to add it and remove 
> patch 5).

But I thought you were pretty keen on getting in this performance
improvement?

> Another benefit of not add MCi_CTL2 is, to avoid difference between 
> Intel and AMD code. Hence I think it's an acceptable approach to keep current 
> vmce (not implement MCi_CTL2). Your opinion?

Current code already handles MCi_CTL2, but incompletely (always
returning zero for reads, and dropping writes). This is valid because
nothing gets announced that should make a guest think it can
access those MSRs in the first place. I do think, however, that
getting this right (and at once getting the guest side polling
disabled) is beneficial, the question just is whether we want to set
the ground for this now, or deal with it after 4.2 went out.

I'm favoring doing it now, and I don't see the strict relationship
to patch #3 - with what we currently implement it would be
sufficient to save zeros and fail non-zero restores (which ought
to fail earlier already anyway, since the implication of the MSRs
here having non-zero values would be for MCG_CAP to have an
unsupported value to be restored too).

Otoh, restoring from saved state that only includes MCG_CAP (but
no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
to be zero, which would be trivial as that's the startup state, i.e.
the only complication here is the variable size save record), so
pushing this to post-4.2 as well is a reasonable alternative.

Keir, Ian?

Jan


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