qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1
Date: Wed, 09 Mar 2011 07:51:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/09/2011 07:14 AM, Avi Kivity wrote:
On 03/09/2011 03:12 PM, Anthony Liguori wrote:
On 03/09/2011 02:51 AM, Avi Kivity wrote:
On 03/08/2011 09:19 PM, Anthony Liguori wrote:
Both the guest and the management agent (and both can listen for events). I don't see why guest->qemu RPC is problematic for migration - at least when qemu terminates it.


If it's terminated in QEMU, it's fine, but then it's not QMP anymore. Let me think about whether there's a way to achieve this without a guest->qemu RPC.

Why not?

{ execute: 'write-keystore' arguments: { 'key': 'foo', 'value': 'bar' } }

This is coming from the guest?

Yes.

So what about:

{ 'KeyStore': { '*foo': 'str', '*otherkey': 'str' } }
[ 'guest-write-keystore', { 'keystore': 'KeyStore' }, 'none' ]

{ 'GUEST_UPDATE_KEYSTORE': { 'keys': [ 'str' ] } }

In this model, the key store is actually stored in the guest. If the guest wants the latest version of a value, it sends an event to get keys updated. The host can update keys at any point in time.

Regards,

Anthony Liguori


QMP doesn't do bidirectional RPC today. It could, but that is a fundamental change in the protocol.


Could use a separate channel for talking to qemu.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]