Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

[Wei Huang <wei.huang2@amd.com>]

On 04/25/2012 11:05 AM, Dan Magenheimer wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: RE: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>
>>>>> On 25.04.12 at 17:01, Dan Magenheimer<dan.magenheimer@oracle.com>  wrote:
>>>>   From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Sent: Wednesday, April 25, 2012 3:27 AM
>>>> To: Boris Ostrovsky; Dan Magenheimer
>>>> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
>>>> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
>>> supported by hardware
>>>>>>> On 20.04.12 at 04:21, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>>>> # HG changeset patch
>>>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>>> # Date 1334875170 14400
>>>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>>>
>>>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>>>>
>>>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>>> Acked-by: Wei Huang<wei.huang2@amd.com>
>>>>> Tested-by: Wei Huang<wei.huang2@amd.com>
>>>> So what's the status of the discussion around this patch? Were
>>>> your concerns all addressed, Dan? Is there any re-submisson
>>>> necessary/planned?
>>> My concerns will be addressed when there is a fully-functional
>>> adequately-tested full-stack implementation, rather than "we
>>> have a new instruction that should solve (part of) this problem,
>>> let's turn it on by default."
>>>
>>> While I wish I could invest the time required to do (or
>>> participate in) the testing, sadly I can't, so I understand
>>> if my opinion is discarded.
>> As Keir had asked to get an ACK/NAK from you - is this then a NAK
>> or a "don't care" or yet something else (it doesn't read anywhere
>> close to an ACK in any case).
> Something else ;-)
>
> I certainly don't feel comfortable ACKing it.  I'd like
> to see some testing that demonstrates the patch either improves
> functionality or performance without breaking other things.
> But if nobody else shares my concern, I don't feel that
> I have the right to block it either.

We can provide some rdtsc performance numbers. Regarding functionality, 
it is relatively hard to prove unless Dan has some more specific ideas 
of testing it. I think the hardware rdtsc scaling is inline with 
software-based emulated approach.

-Wei
>