[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

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.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.