> From: H. Peter Anvin [mailto:hpa@xxxxxxxxx] > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
