From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 4/4] Userspace changes for KVM HPET (v3) Date: Wed, 13 May 2009 10:50:56 +0300 Message-ID: <4A0A7BE0.5060502@redhat.com> References: <1242062986-29383-1-git-send-email-eak@us.ibm.com> <1242062986-29383-4-git-send-email-eak@us.ibm.com> <4A093B49.7010609@redhat.com> <4A0986CD.20601@us.ibm.com> <4A09A35B.5030908@us.ibm.com> <4A0A7B58.9080906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Beth Kon Return-path: Received: from mx2.redhat.com ([66.187.237.31]:51883 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751301AbZEMHx2 (ORCPT ); Wed, 13 May 2009 03:53:28 -0400 In-Reply-To: <4A0A7B58.9080906@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: >>> My assumption about hpet_load was that the correct pit state would >>> be established via pit_load (since all saves/loads are done >>> together). But when I wrote this, I was thinking only about the >>> userspace pit (for qemu). I'm not sure how the "load" concept >>> applies to kernel state. Do I need to explicitly re-enable or >>> disable the kernel pit during load? >> Looking further at the code, it looks like kvm_pit_load should take >> care of this. Agree? >> > > I doesn't save/load the "enabled" bit, does it? > Also, we might migrate between a host with pit-in-kernel and a host with pit-in-userspace, so this is should be handled at the pit level, not kvm. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.