Re: Strange kernel BUG() on PV DomU boot

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2384 bytes --]

On 06/22/12 14:21, Joanna Rutkowska wrote:
> Hello,
> 
> From time to time (every several weeks or even less) I run into a
> strange Dom0 kernel BUG() that manifests itself with the following
> message (see the end of the message). The Dom0 and VM kernels are 3.2.7
> pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
> irrelevant (I think) modifications for Qubes.
> 
> The bug is very hard to reproduce, but once this BUG() starts being
> signaled, it consistently prevents me from starting any new VMs in the
> system (e.g. tried over a dozen of times now, and every time the VM boot
> fails).
> 
> The following lines in the VM kernel are responsible for signaling the
> BUG():
> 
>   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
>         BUG();
> 
> ...yet, there is nothing in the xl dmesg that would provide more info
> why this hypercall fails. Ah, that's because there are not printk's in
> the hypercall code:
> 
>    case VCPUOP_initialise:
>         if ( v->vcpu_info == &dummy_vcpu_info )
>             return -EINVAL;
> 
>         if ( (ctxt = xmalloc(struct vcpu_guest_context)) == NULL )
>             return -ENOMEM;
> 
>         if ( copy_from_guest(ctxt, arg, 1) )
>         {
>             xfree(ctxt);
>             return -EFAULT;
>         }
> 
>         domain_lock(d);
>         rc = -EEXIST;
>         if ( !v->is_initialised )
>             rc = boot_vcpu(d, vcpuid, ctxt);
>         domain_unlock(d);
> 
>         xfree(ctxt);
>         break;
> 
> So, looking at the above it seems like it might be failing because of
> xmalloc() fails, however Xen seems to have enough memory as reported by
> xl info:
> 
> total_memory           : 8074
> free_memory            : 66
> free_cpus              : 0
> 
> Any ideas what might be the cause?
> 
> FWIW, below the actual oops message.
> 

Ok, it seems like this was an out-of-memeory condition indeed, because
once I did:

xl mem-set 0 1800m

and then quickly started a VM, it booted fine...

Is there any proposal of how to handle out of memory conditions in Xen
(like this one, as well as e.g. SWIOTLB problem) in a more user friendly
way?

Any recommendations regarding the preferred minimum Xen free memory, as
reported by xl info, that should be preserved in order to assure Xen
runs smoothly?

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel