All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: Jan Beulich <JBeulich@suse.com>, Don Slutz <dslutz@verizon.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Questions on vpic, vlapic, vioapic and line 0 (aka timer)
Date: Wed, 26 Feb 2014 13:32:15 -0500	[thread overview]
Message-ID: <530E332F.3060901@terremark.com> (raw)
In-Reply-To: <5305D1BC020000780011DEF7@nat28.tlf.novell.com>

On 02/20/14 03:58, Jan Beulich wrote:
>>>> On 19.02.14 at 16:14, Don Slutz <dslutz@verizon.com> wrote:
>> For some TBD reason (very very rarely) the routine timer_irq_works() in linux
>> is reporting that the timer IRQ does not work:
>>
>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>> ...trying to set up timer (IRQ0) through the 8259A ...
>> ..... (found apic 0 pin 2) ...
>> ....... failed.
>> ...trying to set up timer as Virtual Wire IRQ...
>> ..... failed.
>> ...trying to set up timer as ExtINT IRQ...
>>
>> hangs and xen's console is spewing:
>>
>> vioapic.c:352:d1 Unsupported delivery mode 7
>> vioapic.c:352:d1 Unsupported delivery mode 7
>> vioapic.c:352:d1 Unsupported delivery mode 7
>> ...
>>
>> I have determined that the lines (in linux):
>>
>> #ifdef CONFIG_X86_IO_APIC
>>           no_timer_check = 1;
>> #endif
>>
>> that KVM has are missing for Xen.  The simple workaround is to specify
>> "no_timer_check" on the kernel command args.
>>
>> The reason for the email is that I have found the routine
>> __vlapic_accept_pic_intr:
>>
>>       /* We deliver 8259 interrupts to the appropriate CPU as follows. */
>>       return ((/* IOAPIC pin0 is unmasked and routing to this LAPIC? */
>>                ((redir0.fields.delivery_mode == dest_ExtINT) &&
>>                 !redir0.fields.mask &&
>>                 redir0.fields.dest_id == VLAPIC_ID(vlapic) &&
>>                 !vlapic_disabled(vlapic)) ||
>>                /* LAPIC has LVT0 unmasked for ExtInts? */
>>                ((lvt0 & (APIC_MODE_MASK|APIC_LVT_MASKED)) == APIC_DM_EXTINT) ||
>>                /* LAPIC is fully disabled? */
>>                vlapic_hw_disabled(vlapic)));
>> }
>>
>>
>> Which looks to imply that the vioapic supports "delivery mode 7"
>> (dest_ExtINT), but this case is missing (the message logged above).
> Not really - the code above suggests the LAPIC emulation is
> prepared for the IOAPIC emulation to support that mode, not
> that the IOAPIC one supports it. At present only LAPIC LVT0
> really supports that delivery mode.

Well, the linux kernel that I have been testing with only sets LAPIC LVT0 to 7:


         init_8259A(0);
         make_8259A_irq(0);
         apic_write(APIC_LVT0, APIC_DM_EXTINT);


And that agrees with xen-hvmctx:

dcs-xen-54:~/xen>sudo xen-hvmctx 8 | grep -A7 LINT0
       LVT LINT0  : 00000700
         mask     = 0
         trigger  = edge
         rem irr  = 0
         polarty  = active hi
         status   = idle
         delivry  = ExtINT
         vector   = 00

(Patch in the works for this decode).

And the ioapic does NOT have this mode set:

     IOAPIC: base_address 0xfec00000, ioregsel 0x20 id 0
         pin dsm dsa msk trig rir polarity dls  dlm    vec raw
         00: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         01: phys 00  0  edge   0 activehi idle Fixed   49 0x0000000000000031
         02: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         03: phys 00  0  edge   0 activehi idle Fixed   51 0x0000000000000033
         04: phys 00  0  edge   0 activehi idle Fixed   52 0x0000000000000034
         05: phys 00  1  level  0 activelo idle Fixed   53 0x000000000001a035
         06: phys 00  0  edge   0 activehi idle Fixed   54 0x0000000000000036
         07: phys 00  0  edge   0 activehi idle Fixed   55 0x0000000000000037
         08: phys 00  0  edge   0 activehi idle Fixed   56 0x0000000000000038
         09: phys 00  1  level  0 activelo idle Fixed   57 0x000000000001a039
         10: phys 00  1  level  0 activelo idle Fixed   58 0x000000000001a03a
         11: phys 00  1  level  0 activelo idle Fixed   59 0x000000000001a03b
         12: phys 00  0  edge   0 activehi idle Fixed   60 0x000000000000003c
         13: phys 00  0  edge   0 activehi idle Fixed   61 0x000000000000003d
         14: phys 00  0  edge   0 activehi idle Fixed   62 0x000000000000003e
         15: phys 00  0  edge   0 activehi idle Fixed   63 0x000000000000003f
         16: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         17: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         18: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         19: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         20: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         21: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         22: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         23: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         24: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         25: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         26: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         27: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         28: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         29: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         30: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         31: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         32: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         33: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         34: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         35: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         36: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         37: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         38: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         39: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         40: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         41: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         42: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         43: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         44: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         45: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         46: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000
         47: phys 00  1  edge   0 activehi idle Fixed    0 0x0000000000010000

So I am now more confused that vioapic.c is reporting this message.


>> Also linux and xen both set "LAPIC has LVT0" to APIC_DM_FIXED for "Virtual
>> Wire IRQ" usage, but this code only allows for APIC_DM_EXTINT.  I have been
>> able to get "Virtual Wire IRQ" usage to work by adding:
>>
>>                /* LAPIC has LVT0 unmasked for Fixed? */
>>                ((lvt0 & (APIC_MODE_MASK|APIC_LVT_MASKED)) == APIC_DM_FIXED) ||
>>
>> It is not clear to me if it should be added or just changed.
> Adding this to __vlapic_accept_pic_intr() would be contrary to
> the purpose of the function afaict - fixed delivery mode is
> unrelated to delivering PIC interrupts.

So where would be a better place to add this kind of check?

Or is the PIT and HPET not "connected" to LINTIN0 of the lapic?

>> This code looks to state that:
>>
>> ...trying to set up timer (IRQ0) through the 8259A ...
>>
>> is expected to fail.  Is this by design?  (QEMU does allow this case.)
> But in the end I think you're barking up the wrong tree: All of this
> code would be of no interest at all if Linux didn't for some reason go
> into that fallback code. And with that fallback code existing mainly
> (if not exclusively) to deal with (half-)broken hardware/firmware, we
> should really make sure our emulation isn't broken (i.e. the fallback
> never being made use of). So finding the "TBD reason" is what is
> really needed.
>
> Jan
>

I am now sure that I found the base reason in my case.  See:

http://lists.xen.org/archives/html/xen-devel/2014-02/msg02408.html

For my proposed fix.

    -Don Slutz

      reply	other threads:[~2014-02-26 18:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19 15:14 Questions on vpic, vlapic, vioapic and line 0 (aka timer) Don Slutz
2014-02-20  8:58 ` Jan Beulich
2014-02-26 18:32   ` Don Slutz [this message]

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=530E332F.3060901@terremark.com \
    --to=dslutz@verizon.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.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.