Re: [Qemu-devel] KVM call minutes April 3

[Igor Mammedov <imammedo@redhat.com>]

On 04/04/2012 02:14 PM, Michael Roth wrote:
> On Wed, Apr 04, 2012 at 01:53:34PM +0300, Dor Laor wrote:
>> On 04/04/2012 01:37 PM, Michael Roth wrote:
>>>
>>> On Apr 4, 2012 2:42 AM, "Paolo Bonzini"<pbonzini@redhat.com
>>> <mailto:pbonzini@redhat.com>>  wrote:
>>>>
>>>> Il 04/04/2012 03:18, Michael Roth ha scritto:
>>>>> Attacking the IDL/schema side first is the more rationale approach.
>>> From
>>>>> there we can potentially generate ASN.1 BER/DER visitors for the
>>> protocol
>>>>> side, or potentially even just vmstate bindings as a start. I've
>>> recently
>>>>> started looking into the latter... it's completely feasible, the only
>>>>> downside is it complicates the IDL due requiring support for a lot of
>>>>> what are very much vmstate-specific items, but it should be possible to
>>>>> do this in a manner where those annotations are self-contained and
>>>>> ignorable if we opted to replace vmstate-style declarations.
>>>>
>>>> We can also keep the current vmstate descriptions, but access fields
>>>> from the automatically-generated visitors instead of struct fields.
>>>> This keeps the IDL simple.
>>>
>>> It may be worthwhile as an incremental step though, one nice thing about
>>> automatically generated bindings is that with the QIDL Anthony
>>> prototyped a while back we assume we serialize by default, so changes in
>>> annotated structs automatically trigger changes in the generated
>>> bindings unless you explicitly mark fields as immutable/derivable/etc,
>>> which we can tie into the build or make check to automatically detect
>>> and bring attention to changes in vmstate. This may be worth the effort
>>> if we adopt the proposed 4 year migration support cycle for pc-1.0,
>>> since that'll continue to rely on vmstate even after we move on to an
>>> IDL and newer protocol.
>>
>> Beyond ASL/IDL I like to be sure that we're not just translating one
>> format to other representation but instead we introduce some new
>> functionality like:
>>   - Ability to negotiate the protocol version
>>   - Bi-direction data exchange, the sender will send data as a function
>>     of the target release
>>     - Include the machine type too
>
> I've been toying with the notion of having the target start up a QMP
> limited server that the source talks to to orchestrate negotiation. We
> could potentially even send the device state by taking our QIDL-generated
> visitors and serializing state via QmpOutputVisitor. QMP can be made
> aware of the format of the device state input by taking the intermediate
> step of generating QAPI schemas via QIDL, and using the QAPI code
> generators to generate the visitors rather than QIDL directly. This
> would also address the protocol side: just use QMP rather than ASN.1..
>
> It's not as compact, but device state is such a small amount of data
> compared to memory/disk that I don't think it's worth optimizing that
> aspect, though we could use compression at the protocol layer if we
> were inclined. Anything more suited to an out-of-band protocol, like
> memory/disk, could be orchestrated via this interface... source can ask
> target for a port to handle such things, negotiate stuff like XBZRLE,
> etc.
>
>>   - Synchronize the entire qemu cmdline and don't relay on management to
>>     set it up.
>>     - Along the way, deal w/ hotplug events.
>
> My initial plan for the QIDL-generated visitors is to associate a QOM
> property, "state", with each device, and to serialize device state by
> walking the QOM composition tree, the main rationale being that if we
> extend that serialization to include other QOM properties, I believe we
> have everything we need to recreate all the devices on the target:
> parent->child relationships, types, properties set via cmdline,
> device state...
>
> A simpler alternative would be to leverage just send the cmdline
> options over to the target and assume that it results in the same underlying
> machine, then just send off the device state. Much simpler actually...but
> the above approach should work regardless of changes to the command-line
> options on the source... having an internally stable cmdline scheme
> might work as well...
Will command line take in account hot-plugged devices?

>
> I'm not sure what the right approach is here but whatever we decide on I think
> being able to automatically generate visitors from annotations is a good
> first-step and should tie into any forseeable approaches.
>
>>
>>>
>>>>
>>>> Paolo
>>>>
>>>
>>
>

-- 
-----
  Igor