Re: [Xen-devel] [PATCH RFC 3/3] xtf: add minimal HPET functionality test

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.03.18 at 12:46, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/02/18 13:27, Roger Pau Monne wrote:
>> Add a basic HPET functionality test, note that this test requires the
>> HPET to support level triggered interrupts.
>>
>> Further improvements should add support for interrupt delivery, and
>> testing all the available timers.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> ---
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>>  arch/x86/include/arch/lib.h |  14 ++++
>>  docs/all-tests.dox          |   2 +
>>  tests/hpet/Makefile         |   9 +++
>>  tests/hpet/main.c           | 187 
> ++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 212 insertions(+)
>>  create mode 100644 tests/hpet/Makefile
>>  create mode 100644 tests/hpet/main.c
>>
>> diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
>> index 6714bdc..3400890 100644
>> --- a/arch/x86/include/arch/lib.h
>> +++ b/arch/x86/include/arch/lib.h
>> @@ -392,6 +392,20 @@ static inline void write_xcr0(uint64_t xcr0)
>>      xsetbv(0, xcr0);
>>  }
>>  
>> +static inline uint64_t rdtsc(void)
>> +{
>> +    uint32_t low, high;
>> +
>> +    asm volatile ("rdtsc" : "=a" (low), "=d" (high));
> 
> For my own timing purposes, I've been using rdtscp because it is
> strictly more helpful, but this isn't a general solution.
> 
> For rdtsc, (contrary to the way the other thread is progressing), what
> matters is a dispatch serialising event, which is different to an
> architecturally serialising event.
> 
> The easiest fix for now is to unconditionally use mfence, leaving a
> comment saying that this should be lfence on Intel and when the AMD
> pipeline is configured correctly.  Please name the function
> rdtscp_ordered() though, to distinguish it from a plain rdtsc instruction.

Interesting. Right above you say "dispatch serialising", but then
you suggest MFENCE, which isn't on Intel? It's those differences
that I've been trying to explain on that other part of the thread
(apparently with little success, seeing your "contrary to").

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel