From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH] qemu-kvm: Ask kernel about supported svm features Date: Thu, 22 Apr 2010 14:28:02 +0200 Message-ID: <20100422122802.GA28773@8bytes.org> References: <1271933879-15849-1-git-send-email-joerg.roedel@amd.com> <4BD02DE2.9010106@redhat.com> <20100422120249.GW31537@amd.com> <4BD03D5A.6090905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joerg Roedel , Anthony Liguori , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from 8bytes.org ([88.198.83.132]:57705 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751695Ab0DVM2G (ORCPT ); Thu, 22 Apr 2010 08:28:06 -0400 Content-Disposition: inline In-Reply-To: <4BD03D5A.6090905@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Apr 22, 2010 at 03:13:14PM +0300, Avi Kivity wrote: > On 04/22/2010 03:02 PM, Joerg Roedel wrote: >> We can't just take the host-cpuid >> because most of the additional svm features need special emulation in >> the kernel. Or do you think this should better be handled in >> target-i386/cpuid.c? >> > > Yes. -cpu host should take KVM_GET_SUPPORTED_CPUID output and loop it > back to the vcpu configuration, others just take the qemu configuration, > mask it with supported bits, and pass it back (see > check_features_against_host()). Hmm, the plan was to enable with -enable-nesting all kernel supported svm features for the guest (and add switches later to remove them individually) If we activate nested svm with -cpu host in the future thats fine too (closed-source hypervisors need that anyway). But we should also define a cpu model in which we can migrate nested hypervisors between machines were the cpu is not completly indentical. > (need feature names for the bits, too, so you can enable or disable them > from the command line) Yeah, I know. I omitted that for the first bring-up. It was planned for a later patch. Joerg