From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Xen 4.0.0x allows for data corruption in Dom0 Date: Tue, 09 Mar 2010 10:17:55 +0000 Message-ID: References: <4B962DC5020000780003371B@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B962DC5020000780003371B@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" , Joanna Rutkowska , Daniel Stodden List-Id: xen-devel@lists.xenproject.org On 09/03/2010 10:15, "Jan Beulich" wrote: >>>> "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 > 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). Yeah, agreed. We'll stub it out for 4.0.0 I think. Things work quite okay without it. -- Keir