From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Activate Virtualization On Demand v2 Date: Wed, 05 Nov 2008 12:45:46 +0200 Message-ID: <4911795A.6020807@redhat.com> References: <1225874896-13186-1-git-send-email-agraf@suse.de> <49117015.7040902@redhat.com> <49117548.8030601@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, kraxel@redhat.com, anthony@codemonkey.ws, Sander.Vanleeuwen@sun.com, zach@vmware.com, brogers@novell.com To: Alexander Graf Return-path: Received: from mx2.redhat.com ([66.187.237.31]:58827 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754042AbYKEKpz (ORCPT ); Wed, 5 Nov 2008 05:45:55 -0500 In-Reply-To: <49117548.8030601@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: >> We'll be in a nice fix if we can only enable virtualization on some >> processors; that's the reason hardware_enable() was originally >> specified as returning void. >> >> I don't see an easy way out, but it's hardly a likely event. >> > > I don't think there's any way we can circumvent that. > No. We can live with it though. > What I've wanted to ask for some time already: How does suspend/resume > work? The question is important, even without the first word. > I only see one suspend/resume hook that disables virt on the > currently running CPU. Why don't we have to loop through the CPUs to > enable/disable all of them? > At least for suspend-to-disk this sounds pretty necessary. > > Suspend first offlines all other cpus. >>> static int kvm_resume(struct sys_device *dev) >>> { >>> - hardware_enable(NULL); >>> + if (atomic_read(&kvm_usage_count)) >>> + hardware_enable(NULL); >>> return 0; >>> } >>> >>> >> Move the test to hardware_enable()? It's repeated too often. >> > > What do we do about the on_each_cpu(hardware_enable) cases? We couldn't > tell when to activate/deactive virtualization then, as that's > semantically bound to "amount of VMs". > I don't understand. Moving the test to within the IPI shouldn't affect anything. -- error compiling committee.c: too many arguments to function