On Mon, Apr 22, 2013 at 10:39:46 +0800, Li Zhang wrote:
On 2013年04月19日 22:04, Jiri Denemark wrote:
> On Thu, Mar 14, 2013 at 14:54:21 +0800, Li Zhang wrote:
>> From: Li Zhang <zhlcindy(a)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(a)in.ibm.com>
>> Signed-off-by: Li Zhang <zhlcindy(a)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
> 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 :-)
> 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.
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.
Jirka