RE: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly small\!).

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly
> small\!).
> 
> On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
> >
> > It's a bit more complicated than that.  The problem is that if
> > any patch is ever submitted to the kernel that uses the rdtscp
> > instruction *in kernel space* in some clever way, the resultant
> > kernel may not behave as expected (depending on how the instruction
> > is used) on a 32-bit[1] PV kernel running on Xen, up to and including
> > the possibility of data corruption.
> >
> > I don't know how one would implement it, but it's like a
> > BUILD_BUG_ON is needed if any kernel developer uses rdtscp
> > (one that never gets invoked by vdso code), that prints:
> >
> > "WARNING: Please do not use this instruction in the kernel
> > without notifying the Xen maintainer as there is a possibility
> > it may behave unpredictably in some Xen environments.
> > See Documentation/.../xen_pv_limitations for detail."
> >
> > The other virtualization-unsafe instructions may have similar
> > problems.
> >
> 
> Good frakking God.  This is the sort of things that makes me think that
> Xen PV should just be thrown out of the kernel once and for all.

I agree the whole idea of paravirtualization is a hack, but it
is a hack to workaround some poor architectural design decisions
many years ago by Intel processor designers who should have known
better.  Go yell at them.

Worse, the rdtscp instruction was a poor design decision by
AMD processor designers to hack around tsc skew problems.
Go yell at them too.

And both Intel and AMD chose to perpetuate the problem
with a complicated VT/SVM implementation that will never
perform as well as native.  At least they tried ;-)
 
> Do you notice that the document you just claimed doesn't even exist at
> this point, never mind being somehow enforced?  In other word, there is
> ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
> amount of violence Xen does to the architecture that it is parasiting on.

Of course I know it doesn't exist.  I probably should have
noted that in my email.  But it should exist because else
subtle issues like this will get lost in the mist of time.
And I have no clue how to enforce it (though some BUILD_BUG_ON
might help).

Like so many other things in the kernel (and computing in general),
paravirtualization is a tradeoff of maintainability for kernel/software
developers vs significant performance improvement for (a large
number of) users.  That tradeoff is above my pay grade.  But
it does provide job security.