Re: [Qemu-devel] [PATCH] Add VMX cpuid feature to qemu64

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 04.01.2011, at 22:39, Nadav Har'El wrote:

> On Tue, Jan 04, 2011, Alexander Graf wrote about "Re: [Qemu-devel] [PATCH] 
> Add VMX cpuid feature to qemu64":
>> 
>> On 04.01.2011, at 16:06, Nadav Har'El wrote:
>> 
>>> This patch adds the "VMX" cpuid feature to the default "qemu64" CPU type.
>>> If KVM doesn't support this feature (i.e., nested VMX is not in the code,
>>> or not enabled) it will mask out this bit.
>> 
>> "qemu64" defines capabilities that qemu emulates. Qemu does not emulate VMX. 
>> So it doesn't belong there. I thought we had a "kvm64" type for your use 
>> case?
> 
> I have to apologize for making such beginner's mistakes, because I am not
> very familiar with the inner workings of qemu.
> 
> It seemed to me, but please correct me if I'm wrong, that when I use qemu-kvm,
> the default CPU type is "qemu64", not "kvm64", despite my using of KVM.
> In this is true, why shouldn't qemu64 indeed include all the bits that KVM
> may (perhaps) support? I wanted qemu-kvm to support nested VMX whenever the
> underlying KVM supports this, without needing to resort to special "-cpu ..."
> options.

If qemu-kvm still uses the "qemu64" type, that's plainly a bug :). It really 
should use -cpu kvm64 / kvm32 as default.

> I'm not sure what you meant by Qemu emulating SVM as the reason why SVM (but
> not VMX) appears in qemu64's capabilities. As far as I understand, when you
> use KVM, qemu doesn't emulate any of the CPU capabilities - rather, any
> capability that KVM cannot support (such as nested SVM on an Intel processor)
> are removed from the CPUID capabilties list.

KVM is an optional accelerator. The cpu definitions are originally there for 
the TCG backend, so flags that TCG can't handle don't belong there. To work 
around that limitation, the kvm* cpu types were invented.

You can run "qemu-system-x86_64 -cpu qemu64 -enable-kvm" which would disable 
the VMX bit if KVM masks it out. If however you start it with TCG using 
"qemu-system-x86_64 -cpu qemu64", the VMX bit would be set because TCG doesn't 
mask out anything, so you'd essentially break the emulation piece.

> Now that I think of it, perhaps I'm writing to the wrong mailing list?
> Is there a separate mailing list for the development of qemu-kvm, as
> opposed to the "general" qemu? I actually came here after being told by
> the KVM developers to write to the "qemu-devel" mailing list...

The qemu-kvm and qemu trees are getting merged together. In the foreseeable 
future, there will only be qemu and qemu-kvm ceases to exist, because all 
additional functionality of it will be in upstream qemu.

> 
>>> Note that other relevant CPU types, such as "core2duo" already correctly
>>> include the VMX feature, and "qemu64" already includes the SVM feature
>> 
>> "core2duo" really shouldn't include VMX as qemu simply can't emulate it. 
>> Qemu does emulate SVM, hence the bit in the "qemu64" type.
> 
> Well, as you can see in target-i386/cpuid.c, at least in the qemu version
> I checked out from KVM's repository, the "core2duo" and "coreduo" cpu types
> do list the CPUID_EXT_VMX - and those are the only ones that list this 
> feature.

Oops, probably my bad :).

> I don't understand why they should have this bit, and qemu64 not, or,
> alternatively - if none of those had the CPUID_EXT_VMX bit, how am I supposed
> to run qemu to allow KVM to do nested VMX? I can think of some tricks (the
> easiest is to use "-cpu host"), but why should these tricks be necessary
> when they aren't for nested SVM? And when real core2duo CPUs *do* have VMX,
> so if we try to accurately emulate them, we do need to support (nested) VMX?

If you add CPUID_EXT_VMX to the "kvm64" type and make that the default when kvm 
is enabled (like we did for nested svm), all should be well, no?

> Thanks in advance, and again I apologize if I'm missing the obvious, or
> writing to the wrong mailing list.

You wrote to exactly the right mailing list, as this is a qemu issue :).


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk0jlzwACgkQq7Wi27wfN1NpDACfdUAO/Y9zV6/ZAwinCSwPsSNR
05QAn3Zs9ESwBof1DeogBZB/pODlmGHS
=/1lP
-----END PGP SIGNATURE-----