[libvirt] [Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpudefs

Anthony Liguori aliguori at us.ibm.com
Fri Aug 10 14:43:21 UTC 2012


Eduardo Habkost <ehabkost at redhat.com> writes:

> On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
>> Signed-off-by: Anthony Liguori <aliguori at us.ibm.com>
>> ---
>>  target-i386/cpu.c |   22 ++++++++++++++++++++++
>>  1 files changed, 22 insertions(+), 0 deletions(-)
>> 
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index 6b9659f..b398439 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -28,6 +28,7 @@
>>  #include "qemu-config.h"
>>  
>>  #include "qapi/qapi-visit-core.h"
>> +#include "qmp-commands.h"
>>  
>>  #include "hyperv.h"
>>  
>> @@ -1123,6 +1124,27 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf, const char *optarg)
>>      }
>>  }
>>  
>> +CpuDefInfoList *qmp_query_cpudefs(Error **errp)
>> +{
>> +    CpuDefInfoList *cpu_list = NULL;
>> +    x86_def_t *def;
>> +
>> +    for (def = x86_defs; def; def = def->next) {
>> +        CpuDefInfoList *entry;
>> +        CpuDefInfo *info;
>> +
>> +        info = g_malloc0(sizeof(*info));
>> +        info->name = g_strdup(def->name);
>> +
>> +        entry = g_malloc0(sizeof(*entry));
>> +        entry->value = info;
>> +        entry->next = cpu_list;
>> +        cpu_list = entry;
>> +    }
>> +
>> +    return cpu_list;
>> +}
>
> How would the interface look like once we:
> - let libvirt know which features are available on each CPU model
>   (libvirt needs that information[1]); and

I'm not sure I understand why libvirt needs this information.  Can you elaborate?

> - add machine-type-specific cpudef compatibility changes?

I think we've discussed this in IRC.  I don't think we need to worry
about this.

> Would the command report different results depending on -machine?

No.

>
> Would the command return the latest cpudef without any machine-type
> hacks, and libvirt would have to query for the cpudef compatibility data
> for each machine-type and combine both pieces of information itself?

I'm not sure what you mean by compatibility data.

Regards,

Anthony Liguori

>
> [1] Note that it doesn't have to be low-level leaf-by-leaf
>     register-by-register CPUID bits (I prefer a more high-level
>     interface, myself), but it has to at least say "feature FOO is
>     enabled/disabled" for a set of features libvirt cares about.
>
> -- 
> Eduardo




More information about the libvir-list mailing list