[libvirt] [RFC] kvm: x86: export vCPU halted state to sysfs

[Eric Blake]

On 02/02/2018 09:25 AM, Eduardo Habkost wrote:

>>> Markus, Eric: from the QAPI point of view, is it OK to remove
>>> fields between QEMU versions, as long as we follow our
>>> deprecation policy?
>>
>> I would expect that to not be OK.  A fully backwards compatible way to
>> deal with this would just be to add a flag to the query-cpus command
>> eg something like
>>
>>     query-cpus arch-specific=false
>>
>> to turn off all this arch specific state, and just report the cheap
>> generic info. If it defaults to arch-specific=true when omitted, then
>> there's no compat problems.
> 
> This would work, too.  I would name it "full-state",
> "extended-state" or something similar, though.  Not all
> arch-specific data is expensive to fetch, and not all
> non-arch-specific data is unexpensive.
> 
> But I'd like to confirm if it's OK to make existing non-optional
> struct fields optional in the QAPI schema.  Markus, Eric?

If you add an optional bool/enum to opt-in to the command in order to
provide different levels of reporting on output, and the default remains
that when the new input field is absent, all information that was output
in earlier versions of qemu is still output, then you are backwards
compatible.  This is true even if you switched some fields from
mandatory output to optional output, because of the use of the new input
flag for opt-in semantics.  Newer callers that use the opt-in field get
what they want, older callers get what they always expected.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180202/307e2c2c/attachment-0001.sig>