> From: H. Peter Anvin [mailto:hpa@xxxxxxxxx] > Sent: Wednesday, October 17, 2012 11:35 AM > To: Konrad Rzeszutek Wilk > Cc: linux-acpi@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; lenb@xxxxxxxxxx > Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly > small\!). > > On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote: > >> > >> Could you do an audit for other pvops calls that have no users? If > >> the *only* user is lguest, we should talk about it, too... > > > > I can do that - but I don't want to be hasty here. There is a bit of > > danger here - for example the read_pmc (or read_tsc) is not in use right > > now. But it might be when one starts looking at making perf be able to > > analyze the hypervisor (hand-waving the implementation details). So while > > removing read_pmc now sounds good, it might be needed in the future. > > > > We do not keep a pvop around just because it "might be needed in the > future". That's just crazy. > > -hpa 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. Just FYI... Dan [1] I _think_ this is not a problem on 64-bit kernels but am not certain. -- 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
