Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature in guests

[Boris Ostrovsky <boris.ostrovsky@xxxxxxx>]

On 01/19/12 03:46, Keir Fraser wrote:
> On 19/01/2012 08:10, "Jan Beulich"<JBeulich@xxxxxxxx>  wrote:
>
> > > > > On 18.01.12 at 19:26, Boris Ostrovsky<boris.ostrovsky@xxxxxxx>  wrote:
> > > On 01/18/12 04:50, Jan Beulich wrote:
> > > > > > > On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@xxxxxxx>   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




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel