Re: [libvirt] [Qemu-devel] [PATCH qom-cpu 6/9] target-i386: Add "feature-words" property
On 05/03/2013 07:17 AM, Eduardo Habkost wrote:
We could, but maybe it would make the interface harder to use and not
easier?
Even when two feature words are returned in the same CPUID leaf, they
are independent and separate feature-words that must be checked
individually by libvirt, so I believe returning one feature-word per
array-item makes more sense. Having an extra item in the array would
make it clear for libvirt that QEMU has a new feature-word that libvirt
doesn't know about, and easier to spot than an extra field in an
existing array item.
Firmly agree - bundling multiple features into one array item is not nice.
> item[5].CPUID: EAX=7h,ECX=0h
What would be the data type of this "CPUID" field? Are you suggesting
returning a string to be parsed manually?
Anything that requires parsing to break into pieces on the receiving end
implies that it was not correctly represented in JSON in the first
place. I'd much rather see it kept as multiple fields.
>> + for (w = 0; w < FEATURE_WORDS; w++) {
>> + FeatureWordInfo *wi = &feature_word_info[w];
>> + X86CPUFeatureWordInfo *qwi = &word_infos[w];
>> + qwi->cpuid_input_eax = wi->cpuid_eax;
>> + qwi->has_cpuid_input_ecx = wi->cpuid_needs_ecx;
>> + qwi->cpuid_input_ecx = wi->cpuid_ecx;
>> + qwi->cpuid_register = x86_reg_info_32[wi->cpuid_reg].qapi_enum;
> Is there way not to use qapi_enum at all and use name instead?
Are you suggesting making the qapi interface be string-based instead of
using an enum? Why?
enum-based is better than string based. That way, when we add
introspection in qemu 1.6, libvirt can see what enum values to expect,
instead of having an open-ended set of strings with no idea what strings
will be present.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)