On 2013年04月22日 17:10, Jiri Denemark wrote:
On Mon, Apr 22, 2013 at 10:39:46 +0800, Li Zhang wrote:
On 2013年04月19日 22:04, Jiri Denemark wrote:
From: Li Zhang <zhlcindy@linux.vnet.ibm.com>
This patch adds a CPU feature "powernv" identifying IBM Power processor that supports native hypervisor e.g. KVM. This can be used by virtualization management software to determine the CPU capabilities. PVR doesn't indicate whether it a host or a guest CPU. So, we use /proc/cpuinfo to get the platform information (PowerNV) and use that to set the "powernv" flag.
Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com> Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> --- src/cpu/cpu_map.xml | 9 ++ src/cpu/cpu_powerpc.c | 349 ++++++++++++++++++++++++++++++++++++++---------- src/cpu/cpu_ppc_data.h | 4 + src/util/sysinfo.c | 2 +- 4 files changed, 294 insertions(+), 70 deletions(-) Looks like this patch was not even rebased since it was written back in time 1.0.1 was released. Anyway, I realized I did not push my changes to
On Thu, Mar 14, 2013 at 14:54:21 +0800, Li Zhang wrote: powerpc driver so I did that. And I also started rewriting this patch on top of it since this patch is rather huge and seems to mix lots of things. Also PowerPC CPUs seem to be quite different from x86 CPUs so enhancing powerpc driver by copy&pasting code from x86 driver is not the best way :-) It just makes powerpc driver unnecessarily complicated. We hope it matches x86 driver, so most code are from x86. There is no CPUID on powerpc, but we also need feature such as "powernv". And CPUID is what makes x86 driver so complicated. That's why I think it makes more sense to implement the right functionality from scratch rather than copy&pasting x86 driver :-)
OK, you are right.
So what is this "powernv" feature used for? It won't show up in capabilities XML as it is included in all powerpc CPU models. That also This feature means that powerpc can support KVM. Other platform, for example, pseries doesn't support KVM. So we need this feature.
Currently, we haven't introduced this feature in capabilities XML yet.
means, users don't need to explicitly enable it when configuring guest CPU. Thus it could only make sense to allow users to disable this feature for a given guest. However, I don't see "powernv" string anywhere in QEMU source code and thus it cannot really be used in any way in guest CPU definition. This feature is from sysinfo on host, not from QEMU. QEMU haven't included this feature yet. I am not sure whether it is necessary to introduce this to QEMU. I think I understand what powernv feature is but I don't get what it is (planned to be) used for in libvirt. And I'd like to understand that :-) The CPU modeling stuff in libvirt is used for *guest* CPU configuration, i.e., users can configure what CPU model and features the guest should see. So unless you want it to enable/disable something like nested virt, I don't see a lot of sense in introducing such feature. (I may be wrong of course, that's why I'm asking.) Capabilities XML provides some details about host CPU but that's mostly to give an idea about what guest CPU configuration the host could be able to provide.
I see. This feature is read-only. Nested virt isn't considered yet. Actually, I haven't understood this completely. I think PowerPC doesn't support nest virt. I just thought that migration is only allowed with 'powernv'. Currently, only powernv platform can work with KVM. In the future, there may be more features of CPU.
If you want to add powernv feature just because you need to distinguish if the host supports KVM or not, there's much better way... In guest section of capabilities XML, KVM support is indicated by <domain type='kvm'> element. And that's what existing apps already use to detect KVM presence/absence.
As my understanding, there is still some difference from 'kvm' capability. 'powernv' is only considered as one CPU feature of PPC64. If other PPC platforms support KVM in the future, this feature can be used to identify whether migration can be executed . :)
Jirka
-- Li Zhang IBM China Linux Technology Centre