From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Xen 4.0.0x allows for data corruption in Dom0 Date: Tue, 09 Mar 2010 00:48:20 +0100 Message-ID: <4B958CC4.1040105@invisiblethingslab.com> References: <4B922A89.2060105@invisiblethingslab.com> <4B957914.4050408@goop.org> <4B957B93.4060401@invisiblethingslab.com> <4B958475.3050407@goop.org> <4B9586E0.2060005@invisiblethingslab.com> <4B958B14.5030805@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0809604082==" Return-path: In-Reply-To: <4B958B14.5030805@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0809604082== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC533DB72A5E0D5E461ACB2F4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC533DB72A5E0D5E461ACB2F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/09/2010 12:41 AM, Jeremy Fitzhardinge wrote: > On 03/08/2010 03:23 PM, Joanna Rutkowska wrote: >> But the corruptions always happen in 32-bytes chunks, which might >> suggest it's not a page-related problem (e.g. wrongly re-used page), a= s >> in that case we would be observing (at least sometimes) much bigger >> chunks of corrupted data, I think. >> =20 >=20 > Given that the domU doesn't have any devices or much going on, it could= > easily be corrupting memory in only small amounts. >=20 But see, before I tried this with such a small dummy do-nothing DomU (which I did for the purpose of reporting to xen-devel), I experienced very similar corruption when running regular VMs, i.e. with normal linux and all the usual apps inside them. Same pattern of corruption. >> The reason why I still believe it's a hypervisor related thing, it tha= t >> I'm currently using the very *same* Dom0 kernel (very recent >> xen/stable-2.6.31) with Xen 3.4.2 and the system is damn stable. And I= >> really mean extensive use with 5-7 VMs running all the time doing >> various things from Web browsing to kernel building. >> =20 >=20 > OK, it's always good to get some positive feedback. >=20 At least one full-time user of the pvops kernel ;) >> If I was to make an educated guess I would say it's something related = to >> some interrupt handling, i.e. Xen mishandling it, e.g. the handler is >> writing out-of-buffer somewhere and it just happens to land in the Dom= 0 >> fs buffer used by e.g. dd operation. >> =20 >=20 >=20 > It would be interesting to see what happens if you write the file with > the test domain paused (xm pause ...). If the corruption continues, > then it is almost certainly Xen. Right. > If it stops, then it either means the > corruption was caused by pages inappropriately shared between dom0 and > domU, or something like vcpu context switch is corrupting memory (which= > would be very sad). >=20 Unfortunately, I cannot do any more tests. We have downgraded all our test machines to Xen 3.4.2 and are using them for other things now. Sorry= =2E joanna. --------------enigC533DB72A5E0D5E461ACB2F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEUEARECAAYFAkuVjMQACgkQORdkotfEW87AZQCVGWZi3xBpnmef6henYfYAYX5b 5QCg3dYbfUMTxV5HTZPoqU1gIDsHBFI= =yYkZ -----END PGP SIGNATURE----- --------------enigC533DB72A5E0D5E461ACB2F4-- --===============0809604082== 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.xensource.com http://lists.xensource.com/xen-devel --===============0809604082==--