Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced

[Jan Beulich <jbeulich@suse.com>]

On 17.03.2020 16:23, Jason Andryuk wrote:
> On 17.03.2020 15:08, Jan Beulich wrote:
>> On 17.03.2020 15:08, Jan Beulich wrote:
>>> On 17.03.2020 14:48, Jason Andryuk wrote:
>>>> I got it to boot past "IO-APIC + timer doesn't work".  I programmed
>>>> the HPET to provide a periodic timer in hpet_resume() on T0.  When I
>>>> actually got it programmed properly, it worked to increment
>>>> pit0_ticks.  I also made timer_interrupt() unconditionally
>>>> pit0_ticks++ though that may not matter.
>>>
>>> Hmm, at the first glance I would imply the system gets handed to Xen
>>> with a HPET state that we don't (and probably also shouldn't) expect.
>>> Could you provide HPET_CFG as well as all HPET_Tn_CFG and
>>> HPET_Tn_ROUTE values as hpet_resume() finds them before doing any
>>> adjustments to them? What are the components / parties involved in
>>> getting Xen loaded and started?
>>
>> Of course much depends on what exactly you mean you've done to
>> the HPET by saying "I programmed the HPET to provide ...".
> 
> Below is the diff.  It was messier and I tidied it up some.
> 
> It's mainly the change to hpet_resume() to mimic Linux's legacy HPET
> setup on T0.  It turns on HPET_CFG_LEGACY to ensure the timer interrupt
> is running.  And it also includes the printing of the initial HPET
> config:
> HPET_CFG 00000001
> HPET_T0_CFG 00008030
> HPET_T0_ROUTE 0000016c
> HPET_T1_CFG 00008000
> HPET_T1_ROUTE 00000000
> HPET_T2_CFG 00008000
> HPET_T2_ROUTE 00000000
> HPET_T3_CFG 00008000
> HPET_T3_ROUTE 00000000
> HPET_T4_CFG 0000c000
> HPET_T4_ROUTE 00000000
> HPET_T5_CFG 0000c000
> HPET_T5_ROUTE 00000000
> HPET_T6_CFG 0000c000
> HPET_T6_ROUTE 00000000
> HPET_T7_CFG 0000c000
> HPET_T7_ROUTE 00000000
> 
> Other changes are to try to prevent Xen from clobbering T0 as a periodic
> timer.

Why "clobbering"? According to the values above T0 is neither enabled
nor set to periodic.

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -585,16 +585,27 @@ void __init hpet_broadcast_init(void)
>               pv_rtc_handler = handle_rtc_once;
>       }
>   
> +    printk(XENLOG_INFO "%s cfg %d\n", __func__, cfg);
>       hpet_write32(cfg, HPET_CFG);
>   
>       for ( i = 0; i < n; i++ )
>       {
> -        if ( i == 0 && (cfg & HPET_CFG_LEGACY) )
> +        printk(XENLOG_INFO "hpet cfg %d legacy %d\n", i, cfg & HPET_CFG_LEGACY);
> +        if ( i == 1 && (cfg & HPET_CFG_LEGACY) )
>           {
>               /* set HPET T0 as oneshot */
> -            cfg = hpet_read32(HPET_Tn_CFG(0));
> +            cfg = hpet_read32(HPET_Tn_CFG(1));
>               cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>               cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
> +            hpet_write32(cfg, HPET_Tn_CFG(1));
> +        }
> +
> +        if ( i == 0 && (cfg & HPET_CFG_LEGACY) )
> +        {
> +            /* set HPET T0 as periodic */
> +            cfg = hpet_read32(HPET_Tn_CFG(0));
> +            cfg |= (HPET_TN_LEVEL | HPET_TN_PERIODIC);

A change like this of course won't be acceptable outside of
your own repo, but I assume you're clear about this.

Jan

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