From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen 4.2 TODO / Release Plan Date: Tue, 07 Aug 2012 07:38:48 +0100 Message-ID: <5020D418020000780009318C@nat28.tlf.novell.com> References: <1343988573.21372.45.camel@zakaz.uk.xensource.com> <501BC799020000780009278B@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Keir Fraser , Jinsong Liu Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 06.08.12 at 19:06, "Liu, Jinsong" 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