All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH RFC 3/3] xtf: add minimal HPET functionality test
Date: Thu, 1 Mar 2018 11:46:08 +0000	[thread overview]
Message-ID: <ae34d54d-d44e-a624-5e60-3d10854062e3@citrix.com> (raw)
In-Reply-To: <20180223132743.59804-4-roger.pau@citrix.com>

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@citrix.com>
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
>  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.

> +
> +    return ((uint64_t)high << 32) | low;
> +}
> +
> +static inline void pause(void)
> +{
> +    asm volatile ("pause");
> +}
> +
>  #endif /* XTF_X86_LIB_H */
>  
>  /*
> diff --git a/docs/all-tests.dox b/docs/all-tests.dox
> index 355cb80..122840c 100644
> --- a/docs/all-tests.dox
> +++ b/docs/all-tests.dox
> @@ -127,4 +127,6 @@ guest breakout.
>  @subpage test-nested-svm - Nested SVM tests.
>  
>  @subpage test-nested-vmx - Nested VT-x tests.
> +
> +@subpage test-hpet - HPET functional test.

This page is sorted by test category first, but this is the
"in-development" section.

FWIW, I think "in-development" is probably a better category than
utility, because we will eventually want to get this test into automation.

>  */
> diff --git a/tests/hpet/Makefile b/tests/hpet/Makefile
> new file mode 100644
> index 0000000..934e63c
> --- /dev/null
> +++ b/tests/hpet/Makefile
> @@ -0,0 +1,9 @@
> +include $(ROOT)/build/common.mk
> +
> +NAME      := hpet
> +CATEGORY  := utility
> +TEST-ENVS := hvm32
> +
> +obj-perenv += main.o
> +
> +include $(ROOT)/build/gen.mk
> diff --git a/tests/hpet/main.c b/tests/hpet/main.c
> new file mode 100644
> index 0000000..57be410
> --- /dev/null
> +++ b/tests/hpet/main.c
> @@ -0,0 +1,187 @@
> +/**
> + * @file tests/hpet/main.c
> + * @ref test-hpet
> + *
> + * @page test-hpet hpet
> + *
> + * HPET functionality testing.
> + *
> + * Quite limited, currently only Timer N is tested. No interrupt delivery
> + * tests.
> + *
> + * @see tests/hpet/main.c
> + */
> +#include <xtf.h>
> +
> +#define HPET_BASE_ADDRESS       0xfed00000
> +
> +#define HPET_ID                 0
> +#define HPET_ID_NUMBER          0x1f00
> +#define HPET_ID_NUMBER_SHIFT    8
> +
> +#define HPET_PERIOD             0x004
> +#define HPET_MAX_PERIOD         0x05f5e100
> +
> +#define HPET_CFG                0x010
> +#define HPET_CFG_ENABLE         0x001
> +
> +#define HPET_STATUS             0x020
> +
> +#define HPET_COUNTER            0x0f0
> +
> +#define HPET_Tn_CFG(n)          (0x100 + (n) * 0x20)
> +#define HPET_TN_LEVEL           0x002
> +#define HPET_TN_ENABLE          0x004
> +#define HPET_TN_PERIODIC        0x008
> +#define HPET_TN_32BIT           0x100
> +#define HPET_TN_ROUTE_SHIFT     9
> +
> +#define HPET_Tn_CMP(n)          (0x108 + (n) * 0x20)
> +
> +/*
> + * NB: should probably be an explicit movl, but clang seems to generate good
> + * code.
> + */
> +#define HPET_REG(reg) (*(volatile uint32_t *)(_p(HPET_BASE_ADDRESS) + (reg)))

A lot of the above should be in a dedicated hpet driver, rather than in
the test.  See the selftest test_driver_init(), and apic.{h,c} which is
the closes similar example.

That said, HPET registers are in general 64 bits wide rather than 32. 
It is probably best to split the basic hpet infrastructure into a
separate patch from the test.

> +
> +#define MS_TO_NS                1000000
> +/* p is in fs */
> +#define MS_TO_TICKS(ms, p)      (((ms) * MS_TO_NS) / ((p) / 1000000))
> +
> +const char test_title[] = "Test HPET";
> +
> +static uint32_t freq;
> +
> +static void set_freq(void)
> +{
> +    uint32_t eax, ebx, ecx, edx, base;
> +    bool found = false;
> +
> +    /* Get tsc frequency from cpuid. */
> +    for ( base = XEN_CPUID_FIRST_LEAF;
> +          base < XEN_CPUID_FIRST_LEAF + 0x10000; base += 0x100 )
> +    {
> +        cpuid(base, &eax, &ebx, &ecx, &edx);
> +
> +        if ( (ebx == XEN_CPUID_SIGNATURE_EBX) &&
> +             (ecx == XEN_CPUID_SIGNATURE_ECX) &&
> +             (edx == XEN_CPUID_SIGNATURE_EDX) &&
> +             ((eax - base) >= 2) )
> +        {
> +            found = true;
> +            break;
> +        }
> +    }
> +
> +    if ( !found )
> +        panic("Unable to locate Xen CPUID leaves\n");
> +
> +    cpuid_count(base + 3, 0, &eax, &ebx, &freq, &edx);
> +    printk("TSC frequency %ukHz\n", freq);

Calculate what you need in arch/x86/setup.c and export it via
arch/x86/include/arch/cpuid.h

However, you can't rely on the frequency being constant.  It might be
better to busy wait on the percpu wallclock instead, if you don't want
to sort out interrupts.

~Andrew

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

  parent reply	other threads:[~2018-03-01 11:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23 13:27 [PATCH RFC 0/3] hpet: add support for level triggered interrupts Roger Pau Monne
2018-02-23 13:27 ` [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts Roger Pau Monne
2018-02-26 12:35   ` Wei Liu
2018-02-26 12:48     ` Roger Pau Monné
2018-02-26 13:04       ` Jan Beulich
2018-02-26 14:12         ` Roger Pau Monné
2018-02-23 13:27 ` [PATCH RFC 2/3] vhpet: add support for level triggered interrupts Roger Pau Monne
2018-02-23 13:27 ` [PATCH RFC 3/3] xtf: add minimal HPET functionality test Roger Pau Monne
2018-02-23 19:07   ` Wei Liu
2018-02-28 15:37     ` Roger Pau Monné
2018-02-28 16:24       ` Jan Beulich
2018-03-01  9:55         ` Roger Pau Monné
2018-03-01 10:04           ` Jan Beulich
2018-03-01 10:14             ` Roger Pau Monné
2018-03-01 10:22               ` Jan Beulich
2018-03-01 11:46   ` Andrew Cooper [this message]
2018-03-01 12:57     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae34d54d-d44e-a624-5e60-3d10854062e3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.