[Qemu-devel] Re: KVM call agenda for Jan 26

[Avi Kivity]

On 01/26/2010 03:33 PM, Daniel P. Berrange wrote:
> > Me too, especially as the whole stack is involved, and qemu is the
> > topmost part from our perspective (no doubt libvirt will want to
> > integrate that functionality as well).
> >      
> FYI, libvirt already exposes this kind of functionality. The API call
> virConnectGetCapabilities() / command line "virsh capabilities" command
> tells you about what the virtualization host is able to support. It can
> tell you what architectures are supported, by which binaries. What
> machine types are available. Whether KVM or KQEMU acceleration are
> present. What CPU model / flags are on the host. What NUMA topology is
> available. etc etc
>
>    

Great.  Note that for a cpu flag to be usable in a guest, it needs to be 
supported by both kvm.ko and qemu, so reporting /proc/cpuinfo is 
insufficient.  There are also synthetic cpu flags (kvm paravirt 
features, x2apic) that aren't present in /proc/cpuinfo.


--
error compiling committee.c: too many arguments to function