Re: semantics of -cpu host and check/enforce
On 06/11/2011 01:40 PM, Roedel, Joerg wrote: On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote: We have 3 sets of cpu features that may or may not be included in '-cpu host': A) Features that are supported by the host and that KVM can already emulate, or don't need KVM support to be used; B) Features that may be not supported by the host but can be emulated by KVM (e.g. the SVM features, or x2apic); C) Features that are supported by the host but KVM can't emulate. Divided in: C1) features we can't emulate and we know about it (e.g. dtes64)[1] C2) features we possibly can't emulate but we don't even know about it (e.g. features added to recent CPUs). It seems obvious that all the features in group A must always be included in '-cpu host', but what about features in the B or C groups? About group B: it looks like we are not being consistent. For example, svm_features has every bit enabled when using '-cpu host' even if the host doesn't support them; in other cases (e.g. x2apic), it is not enabled by '-cpu host' unless the host already supports it. SVM is a special feature. We can't just forward the host-cpuid to the guest because every SVM feature we provide to the guest needs emulation in the kernel module. The kernel-module will tell qemu-kvm about its feature set via the GET_SUPPORTED_CPUID ioctl. SVM isn't special in this regard. It's potentially true for any feature, and actually true for some of them. So the idea behint -cpu host and SVM features is that qemu-kvm enables all of them and masks out everything that is not supported by the kernel module. Right (but by whitelisting known features, not blacklisting). Note that the kernel might even emulate features that are not supported on the host, like the vmcb-clean-bits, so we really need to ask the kernel what is supported for the guest. x2apic is another example. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: semantics of -cpu host and check/enforce
On 06/11/2011 12:36 AM, Eduardo Habkost wrote: Hi, While checking the cpu model code, I don't think I understand fully what is supposed to be the right semantics for '-cpu host' on qemu-kvm, and what exactly we are aiming to. Maybe this was already discussed before, but I failed to find any additional information except for the original '-cpu host' patch submission. We have 3 sets of cpu features that may or may not be included in '-cpu host': A) Features that are supported by the host and that KVM can already emulate, or don't need KVM support to be used; B) Features that may be not supported by the host but can be emulated by KVM (e.g. the SVM features, or x2apic); C) Features that are supported by the host but KVM can't emulate. Divided in: C1) features we can't emulate and we know about it (e.g. dtes64)[1] C2) features we possibly can't emulate but we don't even know about it (e.g. features added to recent CPUs). It seems obvious that all the features in group A must always be included in '-cpu host', but what about features in the B or C groups? About group B: it looks like we are not being consistent. For example, svm_features has every bit enabled when using '-cpu host' even if the host doesn't support them; in other cases (e.g. x2apic), it is not enabled by '-cpu host' unless the host already supports it. Shouldn't we aim for consistency here and choose one of both approaches? Maybe we want two different model names or options, to differentiate (A) and (A+B)? (maybe something like host and host,+all?) We should choose A+B always, since that's what's supposed to give the best performance. By a lucky coincidence, A+B is the output of KVM_GET_SUPPORTED_CPUID. About group C: If the C group is not empty and 'enforce' is set in the command-line, should we try to enable the feature and consider the missing feature a failure condition, or simply avoid enabling the feature? No, we should fail. But we should allow the user to set a bit even if kvm doesn't think it supports it (but it should be an explicit request). Current semantics of '-cpu host' seems to be: A + all svm features. That means that only part of B is included (all emulated svm features are in, but x2apic is out); '-cpu host' should mean the output of KVM_GET_SUPPORTED_CPUID, no more, no less. group C seems to be excluded entirely (by whitelisting in the kvm kernel code), but the disabled features don't trigger enforce errors. Is that correct? If so, that's a bug. [1] And 3dnow? Why is 3dnow always disabled on qemu-kvm.git/master, at cpu_x86_cpuid()? It's likely due to guests using 3dnow to write to the framebuffer, while kvm doesn't emulate instructions (so, a kvm bug work around). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: semantics of -cpu host and check/enforce
On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote: We have 3 sets of cpu features that may or may not be included in '-cpu host': A) Features that are supported by the host and that KVM can already emulate, or don't need KVM support to be used; B) Features that may be not supported by the host but can be emulated by KVM (e.g. the SVM features, or x2apic); C) Features that are supported by the host but KVM can't emulate. Divided in: C1) features we can't emulate and we know about it (e.g. dtes64)[1] C2) features we possibly can't emulate but we don't even know about it (e.g. features added to recent CPUs). It seems obvious that all the features in group A must always be included in '-cpu host', but what about features in the B or C groups? About group B: it looks like we are not being consistent. For example, svm_features has every bit enabled when using '-cpu host' even if the host doesn't support them; in other cases (e.g. x2apic), it is not enabled by '-cpu host' unless the host already supports it. SVM is a special feature. We can't just forward the host-cpuid to the guest because every SVM feature we provide to the guest needs emulation in the kernel module. The kernel-module will tell qemu-kvm about its feature set via the GET_SUPPORTED_CPUID ioctl. So the idea behint -cpu host and SVM features is that qemu-kvm enables all of them and masks out everything that is not supported by the kernel module. Note that the kernel might even emulate features that are not supported on the host, like the vmcb-clean-bits, so we really need to ask the kernel what is supported for the guest. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
semantics of -cpu host and check/enforce
Hi, While checking the cpu model code, I don't think I understand fully what is supposed to be the right semantics for '-cpu host' on qemu-kvm, and what exactly we are aiming to. Maybe this was already discussed before, but I failed to find any additional information except for the original '-cpu host' patch submission. We have 3 sets of cpu features that may or may not be included in '-cpu host': A) Features that are supported by the host and that KVM can already emulate, or don't need KVM support to be used; B) Features that may be not supported by the host but can be emulated by KVM (e.g. the SVM features, or x2apic); C) Features that are supported by the host but KVM can't emulate. Divided in: C1) features we can't emulate and we know about it (e.g. dtes64)[1] C2) features we possibly can't emulate but we don't even know about it (e.g. features added to recent CPUs). It seems obvious that all the features in group A must always be included in '-cpu host', but what about features in the B or C groups? About group B: it looks like we are not being consistent. For example, svm_features has every bit enabled when using '-cpu host' even if the host doesn't support them; in other cases (e.g. x2apic), it is not enabled by '-cpu host' unless the host already supports it. Shouldn't we aim for consistency here and choose one of both approaches? Maybe we want two different model names or options, to differentiate (A) and (A+B)? (maybe something like host and host,+all?) About group C: If the C group is not empty and 'enforce' is set in the command-line, should we try to enable the feature and consider the missing feature a failure condition, or simply avoid enabling the feature? Current semantics of '-cpu host' seems to be: A + all svm features. That means that only part of B is included (all emulated svm features are in, but x2apic is out); group C seems to be excluded entirely (by whitelisting in the kvm kernel code), but the disabled features don't trigger enforce errors. Is that correct? [1] And 3dnow? Why is 3dnow always disabled on qemu-kvm.git/master, at cpu_x86_cpuid()? -- Eduardo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
