From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] x86/AMD: Add support for AMD's OSVW feature in guests Date: Thu, 19 Jan 2012 10:57:46 -0500 Message-ID: <4F183D7A.5040206@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 01/19/12 03:46, Keir Fraser wrote: > On 19/01/2012 08:10, "Jan Beulich" wrote: > >>>>> On 18.01.12 at 19:26, Boris Ostrovsky wrote: >>> On 01/18/12 04:50, Jan Beulich wrote: >>>>>>> On 17.01.12 at 18:54, Boris Ostrovsky wrote: >>>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum >>>>> 400 as an example -- we don't need a Linux PV guest reading an MSR >>>>> before going to idle (in amd_e400_idle()). >>>> >>>> It is bogus in the first place if a pv guest does so - after all, not doing >>>> stuff like this is the nature of being pv. >>> >>> It was actually a bad example --- the guest is not using amd_e400_idle() >>> and so there are no extra MSR accesses. >>> >>> However, without this change OSVW bit will not show up in the guest's >>> CPUID and I think guests should be able to see it. One could argue >>> whether or not we should mask off status bits for the two errata (400 >>> and 415) since they are not currently used; I'd mask them off just to be >>> consistent with HVM, it won't affect anything. >> >> I continue to think otherwise - knowing of and dealing with this is >> supposed to be entirely hidden from PV guests, unless and until >> you can provide a counter example. Therefore I am likely to nak >> this part of future revisions of the patch (which Keir could >> certainly override), up to and including ripping out the PV part (and >> adjusting the rest accordingly) if I would go for committing it. > > Well, the general principle of exposing OSVW to PV guests doesn't seem > terrible. It's just the current specific motivation for exposing to HVM > guests does not apply to PV guests. > > Are *any* of the current OSVW defined bits at all useful or applicable to PV > guests? > (Wrong "Reply" button) Probably not with current bits, at least for Linux PV guests. -boris