From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Handling of out of memory conditions Date: Fri, 22 Jun 2012 15:11:39 +0200 Message-ID: <4FE46F0B.7080601@invisiblethingslab.com> References: <4FE46366.8010104@invisiblethingslab.com> <4FE46486.8020502@invisiblethingslab.com> <4FE4835D020000780008B6B3@nat28.tlf.novell.com> <4FE46ABE.9010104@invisiblethingslab.com> <4FE48921020000780008B6D0@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2332624385856076604==" Return-path: In-Reply-To: <4FE48921020000780008B6D0@nat28.tlf.novell.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: Jan Beulich Cc: Konrad Rzeszutek Wilk , Marek Marczykowski , xen-devel List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2332624385856076604== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig69CE866BAF9066A9B31E8E85" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig69CE866BAF9066A9B31E8E85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/22/12 15:02, Jan Beulich wrote: >>>> On 22.06.12 at 14:53, Joanna Rutkowska wrote: >> > On 06/22/12 14:38, Jan Beulich wrote: >>>>> >>> > Is there any proposal of how to handle out of memory conditio= ns in Xen >>>>> >>> > (like this one, as well as e.g. SWIOTLB problem) in a more us= er friendly >>>>> >>> > way? >>> >> In 4.2, I hope we managed to remove all runtime allocations >>> >> larger than a page, so the particular situation here should arise >>> >> anymore. >>> >>=20 >>> >> As to more user-friendly - what do you think of? An error is an >>> >> error (and converting this to a meaningful, user visible message >>> >> is the responsibility of the entity receiving the error). In the >>> >> case at hand, printing an error message wouldn't meaningfully >>> >> increase user-friendliness imo. >> >=20 >> > How would you suggest to let the user (in an interactive desktop sys= tem, >> > such as Qubes) know why his or her VM doesn't start? Certainly, some= >> > savvy user might just analyze the guest's dmesg log but that's reall= y >> > not a user friendly solution. And yet the out of memory errors are >> > something that might happen quite often and are not really "exceptio= n" >> > or "errors" in the same sense as e.g. traditional BUG() conditions t= hat >> > suggest something really bad happened. The problem here is that this= bug >> > occurs after the domain has been built, and is now running, so xl st= art >> > is not a good place to return the error. Same with SWIOTLB out of me= mory >> > errors, that again just prevent the domain from starting. Any other >> > ideas how to handle such situations more gracefully? > In the case at hand, failing CPU bringup rather than invoking > BUG() would likely be possible. Then the guest would come up > single-CPU. (That's a more general theme though: Many BUG() > instances really don't need to be as harsh.) >=20 > SWIOTLB allocation is a different thing - if the guest really needs > it, yet fails to set it up, the most it could do is to defer the crash > until the first I/O needs to make use of it. Which likely doesn't buy > much to the user. >=20 How about having the guest kernel (e.g. every time it is about to BUG()) write the cause of the Xen-related runtime errors (such as out of memory conditions) to some predefined xenstore key, which would allow the management tools/whatever other software to retrieve that easily and display a meaningful message to the user? Hm... access to the xenstore might not be easy at the early VM boot stage -- so perhaps writing it into some predefined shared page, that could be easily read by the toolstack? joanna. --------------enig69CE866BAF9066A9B31E8E85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP5G8LAAoJEDaIqHeRBUM0zzMH/jrW69qImpxiwpysyHCWrBo2 kq5bCS9Eept1z0490MvjKwS0jRw/NJ6hzkWgD6HcAV/d+5Hdn+CGxRQE0Ve4DOSH xJ8JH7fVqzfMgAgnmumpkFIVgjEUhkxx+qmiRIJMAfM88NSrXzPiLxhrz/J3Jezz wdJKFIrd5CyaDVcHFtyU6Zb6QYLMx4zWReuC1iq2syyJBpGxxg7IJ459mgCQBqAs OUWHUuf5PvmTI6A2m9XokKHKxnJMhyYqadQpdwI1FrjJ83K5qarRXdmF3HxwWkXw x2JmHV+brie2GzMucRZ44E9q+i2xSNFmu/LVun1yOpMjZJsrHJFiEiu2jTiBGjQ= =OCpT -----END PGP SIGNATURE----- --------------enig69CE866BAF9066A9B31E8E85-- --===============2332624385856076604== 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 --===============2332624385856076604==--