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

Re: [PATCH v2 3/3] x86/hpet: Restore old configuration if Legacy Replacement mode doesn't help


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 29 Mar 2021 14:37:46 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eyBV7zHMzFJCj8rDmDB0bcHX/O+15gumP0+JefsQLyc=; b=V63A7fNP7n6KIEcGiWjwdMhtWivK80v0exD3I/Ao7I6sKBVOIl1FRNn9y5zGnSvi+xpl3H1+EaPwXCgEbmUA5zeb1AuX+1UMaKdReogPvgx1Ush0evBYr1jbs86M8RIeBoP4WI5d3yHGJ1aN/WRcvJFZs+iu6zbmSMFQG/Y+sWmMUzn0eRsE5pSbUzNbP+a8papJ9J/YcTAyhBMn1ya9QADIyvXgD1SrWICAHWe2bAkAHlxBkQ/b68WGEwVZdhYC6Wnl6G539aeO6ST0EsFz1yU2nSbagyyFWPxc0l9xMjhyo8nG4mbmIvMueSk5lQVvgwm5CAEoFpw7TwHFZLm1Zg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zz264yQMqD9j129/wufzTz3FYmi8f4HFoZbf+XjruJXwp2h9GvkearAgoWTIxFuQaO17Qdx8UcjG0ZBpfH0R4hktBKTopkaFDjoeqqGZWBjWvmXf5B1mxmMXRgW+NrWtKVHxSMhD/1VdHFmFseeHCxVgw19SmYLXzCcYx0VEeIleGU84F9ipdubwQsU3qMW8x8X4o9bdwA3O3ZP2RbUCs+oy1Ody72F/jNsNNSqtwO3ATophbIvWuVYqqpwzM19Exa80eiD2dvrNm/Dn0akhmgiT5p/6cqXD/DVn1FaSQtmxcZNXzHqTVGvCftwiAicGKtX7jI1m0D9TVx/QqQq1nQ==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Frédéric Pierret <frederic.pierret@xxxxxxxxxxxx>
  • Delivery-date: Mon, 29 Mar 2021 12:38:22 +0000
  • Ironport-hdrordr: A9a23:aBijpKi54jFIEcnLoPTMeVSqKHBQX2pw3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+YsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmuZ tIW5NVTOf9BV0St6vHySGlDtctx8SG+qi0heHYi0xgVx1udrsI1WZEIyywe3cGIzVuL5w/CZ aa+45rpyC4f24Wc8S8ARA+LpL+jvfMk4/rZgNDOgUu7xOAgSjtxLnxFRWZ2Rl2aUIz/Z4J92 /Znwvlopiyqv3T8G6m60b/zbRz3OHgxNxKGdCWhqEuRAnEpw60aO1aKt+/lR8vpuXH0idOrP DtpFMaM913+zfteAiO0GfQ8i3B9Bpr1HP401+fhhLY0LzEbRY3EdBIi44cUjax0TtYgPhG3K hG332UuvNsZHuq9kSNhKm7azhQmkW5unYkm+II5kYvKbc2U7NNsZcZuHpcDZZoJlOK1KkcDO JsAMvAjcwmF2+yUnaxhBgK/PWcGl43HhuAX3EYvN2U3zV8jBlCvjUl7f1asXEa+J0nTZ5Yo8 zCL6RzjblLCvQbdKRnGY46MIeKI12IZSiJHHOZIFzhGq1CE3XRq6Tv6LFwwO2xYpQHwLY7hZ ypaiIWiUcCP2bVTeGe1pxC9R7ABE+nWy72981Y759l/pXhWbvCK0S4ORATuvrlh89aLtzQWv 61Np4TKeTkN3HSFYFA2BC7c4VOKEMZTNYetr8AKhOzi/OODrevmv3Qcf7VKraoOy0jQHnDDn wKWyW2C95H6mytR3/kkDncU37gYSXEjNBNOZmf29JW5JkGN4VKvARQo0++/Nu3JTpLtbFzXE YWGsKjroqL4U2NuUrY5WRgPRRQSmxP5q/7bn9MrQgWd2f9cbMJvcSjaXlftUH3YiNXfofzKk pytl538aW4I9i73iY5Ee+qNWqckj81qG+VSYwf3omO/93sdJ99LptOYt0+KSz7UzhO3Sp6om ZKbwEJAmXFECn1tKmjhJsIQMfFd9d9hw+vCdVOqW3WsHidoc1HfApZYxeeFeqsxSo+TTtdgV N8t4UFhqCbpDqpIWwjxNgjPEZ0c2SRCrJeBAGjbIFZ84qbPz1YfCOvv3i3mhszcm3l+wE3in b6JSOZQ/3NH2FQo2tVyKrs7VNyeFiMZk4YUAEIjaRNUUD9/lpj2+6CYaS+l1GcbVYP2ckxGj DIazl6GHIk+/mHkDqu3BqSH3QvwZsjetHHBLM4arfJxzeGM4uTj5wLGPdS4bdoPN3jqfUwTO qaYgOZRQmITd8B6kiwnDIIKSN0oH4rnbfUwxXj9nG/x2N6LvzIIlhqLotrVe203izBfbKv35 p4h95u4rf1HWX1d9KcyabYKxREMQjepGaqT+cu7bBY1JhCwIdbLt3+a3/v0noC4TAVaOHTv2 kaSL5g4L/ANpR0FvZiMx5xzx4MrpC3MEAvsgbKGecwclEmsm/DM7qyks/1gItqJnfEmRD5Nl ae+RBM5vvpXyOM0rgBFqI7SF4mH3QU2TBH/OmYcZfXBxjvX+Zf/ECiOnvVSs4WdIG1XZERpA 19+deGgqu+cDf5whnZuX9eLrhV+2iqBeO0DwTkI58Ez/WKfXCNiLCt+si9kXPeTia6cV0Rgc l9TnMrB/4zwwUKvckQySi9Sqv+v0IjnR9/2Fhc5yHQ87njxnzaE0FAORDembNMU1BoQyG1sf g=
  • Ironport-sdr: ZgAQoO9VXWa+Y2aK+SijLq16rkMLFHV7D0IVYS+jDK7TqEs0A3ZWBdDdIEZQkRobj0WxxDiNQp eO3ioKbCIq/DNOoQUQU98A7oTRHX5b+TDAlFJ5/fkw1Qz3/rMrg4vp/rs/5sTSz3TQQb5UkLmn iaHXn4rUVXTNRkqsiy9wCSM9EbNVDyqT1W6Y1Ch0BlikgJ+WHUNbxWVRMdAbZRjtsR8LMAEUEb k9v1/GdjYxscuOgwH7uSaeeBrWwMYOjq3pu1Qsz7haB8ALDHAT2FtCMxA/N5iHP20BvtSkCzXy dMQ=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Mar 26, 2021 at 06:59:47PM +0000, Andrew Cooper wrote:
> If Legacy Replacement mode doesn't help in check_timer(), restore the old
> configuration before falling back to other workarounds.

Oh, I guess this answers my question from the previous patch.

> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> CC: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> CC: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> CC: Frédéric Pierret <frederic.pierret@xxxxxxxxxxxx>
> 
> v2:
>  * New.
> 
> For 4.15: Attempt to unbreak AMD Ryzen 1800X systems.

Is this really the fix for AMD 1800X? I assumed not setting the HPET
into legacy replacement mode unconditionally was the fix for those
systems?

> 
> I'm tempted to fold this into the previous patch, but its presented here in
> isolation for ease of review.
> 
> Tested by repositioning the timer_irq_works() calls on a system with a working
> PIT.
> 
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using old ACK method
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0
> (XEN) ..no 8254 timer found - trying HPET Legacy Replacement Mode
> (XEN) ..no HPET timer found - reverting Legacy Replacement Mode
> (XEN) TSC deadline timer enabled
> ---
>  xen/arch/x86/hpet.c        | 27 ++++++++++++++++++++++++++-
>  xen/arch/x86/io_apic.c     |  4 ++++
>  xen/include/asm-x86/hpet.h |  6 ++++++
>  3 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
> index bfa75f135a..afe104dc93 100644
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -783,6 +783,9 @@ int hpet_legacy_irq_tick(void)
>  
>  static u32 *hpet_boot_cfg;
>  static uint64_t __initdata hpet_rate;
> +static __initdata struct {
> +    uint32_t cmp, cfg;
> +} pre_legacy_c0;
>  
>  bool __init hpet_enable_legacy_replacement_mode(void)
>  {
> @@ -796,8 +799,11 @@ bool __init hpet_enable_legacy_replacement_mode(void)
>      /* Stop the main counter. */
>      hpet_write32(cfg & ~HPET_CFG_ENABLE, HPET_CFG);
>  
> +    /* Stash channel 0's old CFG/CMP incase we need to undo. */
> +    pre_legacy_c0.cfg = c0_cfg = hpet_read32(HPET_Tn_CFG(0));
> +    pre_legacy_c0.cmp = hpet_read32(HPET_Tn_CMP(0));
> +
>      /* Reconfigure channel 0 to be 32bit periodic. */
> -    c0_cfg = hpet_read32(HPET_Tn_CFG(0));
>      c0_cfg |= (HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
>                 HPET_TN_32BIT);
>      hpet_write32(c0_cfg, HPET_Tn_CFG(0));
> @@ -843,6 +849,25 @@ bool __init hpet_enable_legacy_replacement_mode(void)
>      return true;
>  }
>  
> +void __init hpet_disable_legacy_replacement_mode(void)
> +{
> +    unsigned int cfg = hpet_read32(HPET_CFG);
> +
> +    ASSERT(hpet_rate);
> +
> +    cfg &= ~(HPET_CFG_LEGACY | HPET_CFG_ENABLE);
> +
> +    /* Stop the main counter and disable legacy mode. */
> +    hpet_write32(cfg, HPET_CFG);
> +
> +    /* Restore pre-Legacy Replacement Mode settings. */
> +    hpet_write32(pre_legacy_c0.cfg, HPET_Tn_CFG(0));
> +    hpet_write32(pre_legacy_c0.cmp, HPET_Tn_CMP(0));
> +
> +    /* Restart the main counter. */
> +    hpet_write32(cfg | HPET_CFG_ENABLE, HPET_CFG);
> +}
> +
>  u64 __init hpet_setup(void)
>  {
>      unsigned int hpet_id, hpet_period;
> diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
> index 3f131a81fb..58b26d962c 100644
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1955,6 +1955,10 @@ static void __init check_timer(void)
>                  local_irq_restore(flags);
>                  return;
>              }
> +
> +            /* Legacy Replacement mode hasn't helped.  Undo it. */
> +            printk(XENLOG_ERR "..no HPET timer found - reverting Legacy 
> Replacement Mode\n");
> +            hpet_disable_legacy_replacement_mode();

I think you could also get away just calling hpet_disable and
hpet_resume? (bypassing the system_reset_counter check)

Thanks, Roger.



 


Rackspace

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