Unsupported delivery mode 7

Unsupported delivery mode 7

[Chris Webb]

We're running kvm-78 in production on Linux 2.6.27 x86_64 on dual quad-core
Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78
sources rather than the older version bundled with the kernel, and we're
using the NPT features of the processors.

For the most part, everything is performing very well and running reliably.
However, occasionally a guest will hang as it starts (or is reset) with a
large number of messages of the form

  Unsupported delivery mode 7

in the dmesg. Following this, killing and relaunching the qemu process is
usually sufficient to get a working guest.

I'm aware that our versions of the kvm kernel modules and userspace are not
the latest release, but because we're running long-lived guests on behalf of
clients, it's quite a major operation to upgrade. Does this look like a
known bug which has already been fixed or should I try to reproduce it
properly on a test machine with an ability to debug, use magic sysrq, etc?
(It seems impossible to reproduce on my lower spec desktop machine, for what
it's worth. Normally I'd reproduce kernel problems in a KVM virtual
machine---but that's obviously not an option here!)

Am I right in suspecting it might be connected to interrupt delivery
following page migration when a guest moves from one processor to another,
and that a workaround might be to taskset guests to one or other physical
CPU until we're able to upgrade to a more recent version of KVM?

Many thanks in advance for any advice anyone can offer.

Cheers,

Chris.

Re: Unsupported delivery mode 7

[Jan Kiszka]

Chris Webb wrote:
> We're running kvm-78 in production on Linux 2.6.27 x86_64 on dual quad-core
> Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78
> sources rather than the older version bundled with the kernel, and we're
> using the NPT features of the processors.
> 
> For the most part, everything is performing very well and running reliably.
> However, occasionally a guest will hang as it starts (or is reset) with a
> large number of messages of the form
> 
>   Unsupported delivery mode 7
> 
> in the dmesg. Following this, killing and relaunching the qemu process is
> usually sufficient to get a working guest.

The reset issue might be fixed in kvm-userspace.git via commit
888cc6aa65369be5f648a27381aa98569755ac61
(http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff_plain;h=888cc6aa65369be5f648a27381aa98569755ac61).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux

Re: Unsupported delivery mode 7

[Chris Webb]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> The reset issue might be fixed in kvm-userspace.git via commit
> 888cc6aa65369be5f648a27381aa98569755ac61
> (http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff_plain;h=888cc6aa65369be5f648a27381aa98569755ac61).

Thanks! I'll apply that patch to our local kvm tree and watch to see if the
problem has gone. It's much easier for us to switch out the userspace for
testing on the live machines than to switch out kernel modules, as we don't
need to kill all the existing guests to do it.

Best wishes,

Chris.

Re: Unsupported delivery mode 7

[Marcelo Tosatti]

On Wed, Nov 19, 2008 at 12:54:29PM +0000, Chris Webb wrote:
> We're running kvm-78 in production on Linux 2.6.27 x86_64 on dual quad-core
> Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78
> sources rather than the older version bundled with the kernel, and we're
> using the NPT features of the processors.
> 
> For the most part, everything is performing very well and running reliably.
> However, occasionally a guest will hang as it starts (or is reset) with a
> large number of messages of the form
> 
>   Unsupported delivery mode 7
> 
> in the dmesg. Following this, killing and relaunching the qemu process is
> usually sufficient to get a working guest.
> 
> I'm aware that our versions of the kvm kernel modules and userspace are not
> the latest release, but because we're running long-lived guests on behalf of
> clients, it's quite a major operation to upgrade. Does this look like a
> known bug which has already been fixed or should I try to reproduce it
> properly on a test machine with an ability to debug, use magic sysrq, etc?
> (It seems impossible to reproduce on my lower spec desktop machine, for what
> it's worth. Normally I'd reproduce kernel problems in a KVM virtual
> machine---but that's obviously not an option here!)
> 
> Am I right in suspecting it might be connected to interrupt delivery
> following page migration when a guest moves from one processor to another,
> and that a workaround might be to taskset guests to one or other physical
> CPU until we're able to upgrade to a more recent version of KVM?
> 
> Many thanks in advance for any advice anyone can offer.

On 2.6 guests this kernel option can workaround the bootup problem:

        no_timer_check  [X86-32,X86_64,APIC] Disables the code which tests for
                        broken timer IRQ sources.