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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:

> On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
>> Signed-off-by: Anthony Liguori <aliguori@xxxxxxxxxx>
>> ---
>>  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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]