From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: VMSTATE_U64 vs. VMSTATE_UINT64 Date: Wed, 04 May 2011 20:24:11 +0200 Message-ID: <4DC199CB.30001@siemens.com> References: <4DC19538.8010207@siemens.com> <1304532978.4737.32.camel@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Juan Quintela , kvm To: Glauber Costa Return-path: Received: from thoth.sbs.de ([192.35.17.2]:26673 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751008Ab1EDSYR (ORCPT ); Wed, 4 May 2011 14:24:17 -0400 In-Reply-To: <1304532978.4737.32.camel@mothafucka.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-05-04 20:16, Glauber Costa wrote: > On Wed, 2011-05-04 at 20:04 +0200, Jan Kiszka wrote: >> Hi guys, >> >> can anyone comment on commit e4d6d49061 ("introduce VMSTATE_U64") in >> qemu-kvm again? I strongly suspect this thing was only introduced to be >> able to grab from a __u64 (for kvmclock) without generating a compiler >> warning that you may got when using uint64_t, right? >> >> Thanks, >> Jan >> > I don't remember if it was kvmclock. IIRC, it was my irqchip > implementation at the time. But I do remember the reason: it was indeed > to be able to grab kernel data structures directly without a compile > warning. > Perfect. Then I will also include a revert/drop patch in my series that switches the only user, kvmclock, to the upstream version. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux