From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Strange kernel BUG() on PV DomU boot Date: Fri, 22 Jun 2012 14:26:46 +0200 Message-ID: <4FE46486.8020502@invisiblethingslab.com> References: <4FE46366.8010104@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3010769908683817745==" Return-path: In-Reply-To: <4FE46366.8010104@invisiblethingslab.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xensource.com" Cc: Marek Marczykowski List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3010769908683817745== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig75F3E5CEB4B69EC053ACB8F1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75F3E5CEB4B69EC053ACB8F1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/22/12 14:21, Joanna Rutkowska wrote: > Hello, >=20 > 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. >=20 > 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 boo= t > fails). >=20 > The following lines in the VM kernel are responsible for signaling the > BUG(): >=20 > if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt)) > BUG(); >=20 > ...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: >=20 > case VCPUOP_initialise: > if ( v->vcpu_info =3D=3D &dummy_vcpu_info ) > return -EINVAL; >=20 > if ( (ctxt =3D xmalloc(struct vcpu_guest_context)) =3D=3D NULL = ) > return -ENOMEM; >=20 > if ( copy_from_guest(ctxt, arg, 1) ) > { > xfree(ctxt); > return -EFAULT; > } >=20 > domain_lock(d); > rc =3D -EEXIST; > if ( !v->is_initialised ) > rc =3D boot_vcpu(d, vcpuid, ctxt); > domain_unlock(d); >=20 > xfree(ctxt); > break; >=20 > 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: >=20 > total_memory : 8074 > free_memory : 66 > free_cpus : 0 >=20 > Any ideas what might be the cause? >=20 > FWIW, below the actual oops message. >=20 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. --------------enig75F3E5CEB4B69EC053ACB8F1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP5GSGAAoJEDaIqHeRBUM0b+QIAK4TooH+Hq4aYwZ/uTiqfUcb X4gpssHo5/96uPWNeqR19J3Hg5rm1+QHJjvRGaxOluBqZicTH0D9iypZAdYxlE87 5AYDbi2U3LChHEwoC4t+5N9N6e0yTd78Hy9m4MxVk/EpHEzhXmMbOqMEMV+q86ZY 9JTkB00RSex0viZqKyfMYXLKostGPPEOHh7W2oYYBVpiTa2AxQTTzCl6m9Cvkfn6 LXkwO6iCE3I/sNMgmwZlJxYzf+hVTJK/XTXYfJ9qnVMIukbdQN8A2mIcxPQ5C5do 6AWkMIzs6owOpkBwOFiB3sAkaj7mYIzneBpB8FC4jRIiNpuFCIF/IFtm8MREC+Y= =ymiY -----END PGP SIGNATURE----- --------------enig75F3E5CEB4B69EC053ACB8F1-- --===============3010769908683817745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3010769908683817745==--