From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen 4.0.0x allows for data corruption in Dom0 Date: Tue, 09 Mar 2010 10:15:17 +0000 Message-ID: <4B962DC5020000780003371B@vpn.id2.novell.com> References: <20100307143631.GO2580@reaktio.net> <20100307161256.GQ2580@reaktio.net> <1268090552.27980.288.camel@agari.van.xensource.com> <20100309082534.GH2580@reaktio.net> <4B9624FD02000078000336EA@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4B9624FD02000078000336EA@vpn.id2.novell.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Joanna Rutkowska , "xen-devel@lists.xensource.com" , Keir Fraser , Daniel Stodden List-Id: xen-devel@lists.xenproject.org >>> "Jan Beulich" 09.03.10 10:37 >>> >How about these being vcpu_time_info structures? The fields >appear to all make sense. The only thing not matching this would >be a few differently looking corruption entries sent earlier by Joanna, >so this may not be the only thing. But it would explain why with 3.4.2 >the issue is not present. In particular I think the update_vcpu_system_time() invocation=20 in schedule() isn't right - VCPUOP_register_vcpu_time_memory_area taking a virtual address, this call must not happen before context_switch(). And btw., 32-on-64 also seems to be broken for VCPUOP_register_vcpu_time_memory_area (since 64-bit Xen reads the full 64-bit field). Jan