From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: No kernel interface to reset a VCPU Date: Fri, 25 Sep 2009 16:52:05 +0200 Message-ID: <4ABCD915.5090503@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit To: kvm-devel Return-path: Received: from goliath.siemens.de ([192.35.17.28]:16195 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716AbZIYOwE (ORCPT ); Fri, 25 Sep 2009 10:52:04 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n8PEq6dg019413 for ; Fri, 25 Sep 2009 16:52:06 +0200 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n8PEq5O6003986 for ; Fri, 25 Sep 2009 16:52:06 +0200 Sender: kvm-owner@vger.kernel.org List-ID: Hi all, looks to me like there is no way to properly reset the boot processor. The current pattern used by qemu[-kvm] is to reload all registers with their reset values. But that does not affect the internal VCPU states the KVM keeps in the kernel. They are only reset during VCPU setup or after receiving a SIPI (and the latter only helps with secondary CPUs). So the only way around it with the current kernel interface is to destroy/recreate the BSP on reset, right? /me is looking into such an approach now. We stumbled over inconsistent VCPU states with our internal qemu-kvm tree. We have a legacy watchdog emulation here that triggered but failed to bring up the system again. I wasn't able to create a similar case with a standard environment yet, but I think it is not unrealistic for qemu-kvm as well. Hacking kvm_arch_vcpu_reset() into KVM that triggers on the right register values "solved" the issue here. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux